At 11:43 22.03.00 -0500, John_Gardner at dmr.ca wrote:

>[...]
>However, I am concerned on two counts.
>[...]

>2. Widgets
>Everything today seems to be focused upon Morphic. While it has many
features,
>which make Java look sick, it is big and slow compared to MVC.
>
>In the Java world, you have two options, use AWT or Swing. AWT is
analogous to
>MVC, while Swing is somewhat analogous to Morphic. If you are writing
applets,
>it is recommended that you use AWT for speed and compactness.

If I look at both implementation, I compare the design.  Both aren't
perfect IMHO but I consider Morphic more flexible than MVC.  For a really
good design, look at the MVP framework of Dolphin Smalltalk.  Separation of
model and view is a must nowadays but I don't think that the separation of
view and controller is a good idea.  In MVP, the view ("V") is both, acting
like a self contained widget.  You might even call this combination a
morph.  What's missing in MVC and Morphic is where the application logic,
the glue between the GUI and the domain model, should be implemented.  In
MVP it's the "P", the presenter.  The way dolphin uses these MVP triads,
you can encapsulate and combine them to larger GUIs.

My point is, don't compare AWT with MVC and Swing with Morphic in other
terms as that AWT is older as Swing as MVC is older as Morphic.  The
problem with Swing, btw, is it's really poor implementation.  I always feel
pain and the urge to change the code if I have to look into Swing's source
code.  And as a Smalltaker I'm used to the idea to ask the source if I want
to know how something happens (or more often - why something doesn't work).

Morphic is still a bit slower than MVC, that's right, but it provides more
features: for example support for translucence, rotation and scaling,
multiuser support or drag and drop.  The difference in speed will probably
shrink in near future.  Careful analysis of the code will reveal the bottle
necks.

What's bad with Morphic that it can be often used as an example for bad
Smalltalk.  The clases are too large (key classes have too many methods),
it's not very well documented and too many features like players or
stepping have been put into the base class Morph instead of having been
factored out.

>Similarly, wouldn't it be a good idea to have a core set of widgets developed
>for MVC, when speed and compactness are needed?

I'd like to see a Morphic-lite, something stripped from all ballast, down
to the core functionality of MVC but compatible to the normal Morphic
system and with multiuser support, better screen redraw and color support.

But IMHO it would be much easier both for the user to learn just one UI
framework and the tools which need only support one way of constructing GUIs.


>A lot of OS system functions could be developed using Squeak and MVC-Widgets,
>instead of using Perl/Tcl/Python.

Yes, if it's okay for you that Squeak always opens its own screen instead
of showing just a window like all other programs.

>MVC-Widgets. Perhaps a combination of the embedded Squeak and MVC-Widgets
as a
>core package, which is then built-up, as required, to include Morphic,
Fabrik,
>Alice and Wonderland.
>
>Does anyone else think this approach has merit?

I also used to be in favor of adding packages than of removing
functionality but when you have to add and test changes to the system, it's
very handy to have everything in place by default.

As an alternative, I'd suggest that there's a very prominent way, i.e. a
simple to use GUI, to strip away unneeded parts of the system.  And for the
meantime, check out the methods of SystemDictionary which have some support
to remove subsystems from Squeak.  This isn't perfect yet but you can get
rid of Alice or whatever very easy.

bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf.