Hello Squeakers,

Let me say that I'm enjoying the responses to my email. Thank you all so much.

However, I want to clarify some perceptions:

1. I am not dissing Morphic.
It is truly incredible and extensible. It is an excellent UI. However, it is BIG
and somewhat slower than MVC. While the speed issue may be resolved through
tuning, size is still an issue. Perhaps the bytecode compiler could be extended
to provide information to a "discard..." method which would remove all
unnecessary classes. This would be an option, of course, and it would only work
at the system category (application) level. The context here is creating
applications for end users.

2. Please forget the AWT and Swing analogy.
This was an attempt to relate my Java experience to Squeak. The statement was
never intended to be an accurate comparison. It was meant to convey the Java
reality that when you want small, compact, fast code with a GUI, it is
recommended that you use AWT classes instead of Swing classes. This is
especially true when creating applets, which are downloaded over the Internet.

3. Is there a bias toward MVC and MVC-Widgets?
Again, I am not dissing Morphic. Yet, the impression I am getting is that there
is a bias against using MVC. If there is no capability at "compile time" to
remove unnecessary classes and optimize the code in a Morphic application, then
we have lost the game. Speed and size are relevant.

Thanks,

John.





Stefan Matthias Aust <sma at 3plus4.de> on 03/23/2000 03:12:39 PM

Please respond to squeak at cs.uiuc.edu

To:   squeak at cs.uiuc.edu
cc:    (bcc: John Gardner/DMR/CA)
Subject:  Re: Widgets and Books for Squeak



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.