[UI] ToolBuilder

[Bill Schwab]

Jason,

I respectfully submit that you are indeed off base :)  My goal is to
build that serve various types of users.  The end users are generally
served by my efforts, which tend to accumulate over time; I do not want
to lose that work, so I want it in a somewhat abstract form, or at least
convertible to such a form.  I am served by the IDE, which I want to
have a feel that stands up to my debugging sessions, but I do not want
to make a living out of rewriting the tools.  If Squeak has builders for
them, I would be willing to work to subclass them to use Gary's themes.

Squeak is probably the least likely of the existing Smalltalks to simply
disappear, but while I hope it will change enough to allow me to use it,
it might subsequently be mutated into something I would later not want
to use.  It is also possible that another open or commercial system
would appear to which I would want to migrate.  Again, it pays to have
some abstraction.

Finally, one wants both graphical drag-and-drop GUI builders, and
convenient ways to build from code.  Consider writing a GUI to match a
large existing database schema.  One can iterate tables, field names and
types, and end up with (forgive the MVP bias) views and presenters (code
too!)  that has most of the details in place.

Yes, Squeak should have a graphical view editor; it should also have
ways to build views in code.  It should also provide ways to insulate
projects from Morphic, both to aid porting to or away from Squeak, and
to allow the use of something better should Squeak provide it.  As an
aside, Tweak makes me nervous because of compiler changes.  The same
results could be obtained in Smalltalk as-is with a parallel/extended
events system and/or other builder tools; changing the language to hide
complexity, IMHO, violates Beck's "lots of little pieces" mantra, which
has kept me out of lots of trouble over time.

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 09/09/07 2:31 AM >>>
On 9/9/07, Matthew Fulmer <tapplek at gmail.com> wrote:
>
> The best thing to do would be store the created morph in some
> dictionary, then clone it when you want a new instance.  Code is
> much less manipulable than objects, and is not what the user
> should be concerned about. So better to leave it out of the
> picture entirely.

So if we find a way to solve this obviously solvable issue of saving
objects to file (we do that right now for the image) can Morphic be
used as described in Self?

I mean, my understanding of Self is that since you have no
meta-classes only objects, working in the system is like working in
Smalltalk inspectors and debuggers only.  And this is a nice, fun way
to work in Smalltalk as well when working with objects.

I think working this way is the advantage to Morphic and if we can't
do that then perhaps we should just decide that Morphic was made for
Self, not Smalltalk and move on.  It feels like trying to force a
solution where it doesn't belong when we talk about making builders
for Morphic.  Morphic should, itself, be the graphical builder for
Morphic applications and if it can't then what is it really bringing
besides a name?

Again, if I'm off base here, please help me out.
_______________________________________________
UI mailing list
UI at lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/ui