[UI] UI plan, my thoughts

[Douglas Rollwitz]

Hi;

I also would like a more standard UI development tool,
one that we can use for "normal" UI development.  For
a few years I extended a tool called BobsUI, trying to
get it to that capability.  The more I added to it,
the more I noticed some fundamental problems with the
code however, and decided it needed a big refactoring.
I dropped supporting it due to a lack of time, but I
would like to pick it back up, and have others
participate as well.  It needs a lot of work, but I
also believe it can be a very good tool.

While my goal for BobsUI is for it to be a standard
business UI builder, it looks nothing like a standard
UI builder.  This is because I was trying to improve
on the standard UI builders, and have it fit into the
Squeak paradigm.    

I will be creating a BobsUI page on the swiki soon,
which will go over the design and future direction I
would like it to have.  You can download BobsUI from
the Squeak Map.

Because of the work in BobsUI, I have come to the
conclusion that the Moroh-HaloMorph-Halo relationship
needs to be refactored.  I actually did this once a
few years ago, but lost the code in a hard disk crash.
 Currently I am working on recreating this code
enhancement.  I will write another email on that work.
 

Doug

--- Jason Johnson <jason.johnson.081 at gmail.com> wrote:

> Hi all,
> 
> It was asked that we make a new thread for what we
> think should be
> done here so here is mine (the ones we all agree on
> like consistency
> not listed here):
> 
> 1) We need a means of building GUI's graphically. 
> If Squeak is to
> become viable for building business GUI applications
> the way Dolphin
> is/was it making a GUI can't mean writing code
> describing what widgets
> to use and where to put them.  Even C has good ways
> to do this
> graphically.  We should to.
> 
> 2) We need a good framework to build this on.  I
> recommend we look at
> the Dolphin papers about MVP and use that.  It's
> like MVC but imo
> factors better (the control and view are merged, but
> afaik they always
> were anyway).  This sort of thing is easy to
> overlook, but having a
> good framework to build on makes it easier to know
> what classes should
> have what responsibilities.  This is one of the
> things I feel is wrong
> in Morphic: it seems as though it wasn't so obvious
> where the
> boundaries were between responsibilities.  By not
> having this you end
> up with.... well what we have now. :)
> 
> Hrm, well I guess that's it for now.
> 
> Thanks,
> Jason
> _______________________________________________
> UI mailing list
> UI at lists.squeakfoundation.org
>
http://lists.squeakfoundation.org/mailman/listinfo/ui
>