[UI] C# methodologies

[Jason Johnson]

On Jan 14, 2008 9:23 PM, Bill Schwab <BSchwab at anest.ufl.edu> wrote:
> Jason,
>
> I probably did misunderstand you.  Dolphin's ViewComposer does some of
> what you describe, but I suspect that Object Arts would be the first to
> agree that it could be done better.  It might be interesting to look at
> WindowBuilder (if we can find a copy of Smalltalk Express or something
> else that has it and then get it to run), Dolphin Community Edition, and
> Squeak/Morphic.

I'm still go looking for documentation on Morphic from time to time to
try to figure out what the advantage is.  So far my impression is that
it was a good idea from Self that just doesn't translate well to
Smalltalk.  And it sounds like the API is terrible.

>  I think the correct solution merges a code generator
> with a visual editor, the nature of which might change with the views
> (e.g. Morphic, wx, etc.).  I have long done the code and view generator
> in a "batch" mode to generate GUIs based on various meta data sources.

At this point I'm not so big on generating views from "batch" mode,
but the system I envision would be in pure Smalltalk so it wouldn't
know or differentiate between receiving messages from code or from a
designer application.  I certainly wouldn't go out of my way to stop
people from doing something they want to do.

> There is a Dolphin solution that approaches it from the view, IIRC,
> generating code to match it.  I should dig around for it and add it to
> our list of examples.  Throw anything else you want in with it, stir,
> and plan a GUI editor.  Is that closer?

Well, that's probably further then I had thought about at this point.
I just noticed the C# ability to let one go very far in application
development purely in the visual builder and think that would be nice
to have in Smalltalk.

Of course there are times one needs extreme flexibility in building a
system but the vast majority of applications don't require nearly that
much work.  When I look at the free software world around us one thing
that sticks out to me is that these guys who do this in their precious
spare time are writing their graphical applications in C (!!!).  Why
is that?  Why wouldn't one use Smalltalk to slap together a GUI in a
day?

I want to change that.  I want to make a graphical building system
that lets one build GUIs so fast that nearly everything in use on
Linux could be duplicated in such a short time that the productivity
can't be ignored.  The Smalltalk and Lisp communities always talk
about how much more productive we are (and I believe that), but we're
not showing it.

>BTW, just because I advocate
> against volatile changes to the language, please do not feel like we
> have to stick to ST-80.  I would very much like to see Squeak more fully
> embrace exception handling, as well as provide shortcuts to avoid the
> overhead (such as using #at:ifAbsent: vs. having to catch errors from
> #at:).

I really like #ifAbsent: and use that pattern in my own code.

By "stock ST-80" I just meant not adding any language extensions.  The
libraries need to always be advancing.  For example, Smalltalk has
resumable exceptions.  Having known about them from Lisp I thought
that was good that they have them.  But when one looks at how they
look when used it leads to some pretty ugly hard to understand code.
One thing I would like to explore at some point is adding Lisp-style
restarts to Smalltalk so this would not only look better but be (imo)
state of the art.

> Squeak does it in some places and not others.  If you want to
> call that "Smalltalk 95" or so, I'd let you get away with it.  Dolphin
> and VW do some related things quite wel, and IMHO, Squeak should "learn"
> from them.

Agreed.