[UI] Re: MenuMorph hand weirdness

[Bill Schwab]

Jason,

Agreed about a graphical view editor - it is a must for many kinds of
things.  However, five years or so ago, a friend and colleague of mine
needed to store several hundred data points on each of 100+ patients. 
It is small time compared to much of the database work that goes on in
the world, but it was big for us.  Note that "us" turns into "***ME***
(gulp!)" when it comes to making work.  I actually tried to build it
using Access (trying to do it the "accepted" way), and it was starting
to look like a disaster in the making.  I then turned to Dolphin and
began scripting the view composer; with some tweaks, the image survived
it, and it soon turned into quite a display of Smalltalk's power.

A similar trick will be necessary for a sombre task: converting a LOT of
GUI code and view resources to another Smalltalk system.  That process
will be essential to a robust port, and will provide a lot of testing
for a new MVP framework.  It is a natural place for me to start any
serious port attempt, hence the focus.

I share you desire for a graphical view editor.  Do you have any
thoughts on how to build it given that "views" will include morphs, svg
structures, and even native widgets?

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwab at anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> jason.johnson.081 at gmail.com 11/20/07 2:34 PM >>>
On Nov 20, 2007 2:50 AM, Gary Chambers <gazzaguru2 at btinternet.com>
wrote:
>
> This was a question to gauge the importance of having menus themed as
> standard, in the general IDE sense... more of fixing what we have
rather
> than the new big thing.
>
> In terms of "the new big thing" I think we have to become very much
more
> focussed. That means really working together. Perhaps everyone could
make a
> prototype system to demonstrate to us all... then work together with
the
> best bits?
>
> As a start, we should be able to easily conform to any particular
"look and
> feel"... take the Java abstraction classes as an example. We could
also
> incorporate "native" (Win32/GTK) as part of the framework (different
to the
> "emulated" Java). I'd really like anything we do to be non-exclusive
and
> all-encompassing, both potentially attainable goals.
>
> Might sound a bit "bloaty" but a framework that can plug-and-play our
> concepts would be nice...

I think this is all very doable within MVP and in fact MVP would make
this sort of thing much easier to do, since very little if any code
would depend on what view was being used.

> I think it comes down to the way(s) you want to be able to describe a
> user-interface. Need to be able to express the intention of the ui in
a
> flexible manner but, also, for some applications, have exact control
(plus a
> lot of in-betweens). ToolBuilder does a lot of that, but is not yet
rich
> enough to do the latter...

Personally I prefer to use a graphical tool to draw exactly the
interface I want, but different people want different things, so
having a nice framework that can support all of us is the answer I
believe.
_______________________________________________
UI mailing list
UI at lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/ui