[UI] C# methodologies

[Bill Schwab]

Jason,

Morphic's API certainly leaves room for improvement.  My main interest
in it is that it works and can get us to whatever we decide to do next. 
Given that, it seems reasonable to consider it as one of our view
hierarchies of interest.

The more you describe what you want to do, the more I think about
WindowBuilder.  I appears to be alive and well via Instantiations and
VA, but it should also live in Smalltalk Express.  If we can get that to
run, you will quickly get an idea of what it can do.  The following
might work (subject to AV checks, etc.):

   http://www.smalltalk.org/versions/SmalltalkExpress.html

The patches probably refer to some changes to get it to run on "high"
color depth video systems (aka, almost anything in use now<g>).


The "other" Dolphin-based generator I mentioned can be found here:

   http://www.cjd77.com/smalltalk/PresenterGenTool.htm


I share your surprise at the way the rest of the world writes software. 
I could draw political analogies for it, but suffice it to say that I
doubt the situation will change much.  All of us found Smalltalk, and
others will too, provided dialects continue to exist and remain viable.

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 01/15/08 1:11 PM >>>
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.
_______________________________________________
UI mailing list
UI at lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/ui