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@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
jason.johnson.081@gmail.com 11/20/07 2:34 PM >>>
On Nov 20, 2007 2:50 AM, Gary Chambers gazzaguru2@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On Nov 20, 2007 9:15 PM, Bill Schwab BSchwab@anest.ufl.edu wrote:
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.
Interesting. Yes, I know there is a need, and that some people simply prefer coding the GUI in general. I'm glad we don't have to be exclusive.
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?
Well, honestly if it falls behind far enough that I wind up doing it, I had planned on being lazy and just creating the graphical editor for one kind of view. I don't think it hurts for every different kind of view to have it's own editor. All that *must* happen is that the resulting views respond to the expected protocol.