On Monday 30 August 2004 8:34 am, Avi Bryant wrote:
> On Aug 30, 2004, at 4:02 PM, Ned Konz wrote:
> > On Monday 30 August 2004 4:43 am, Pavel Krivanek wrote:
> >> IMHO developers are frustrated by Morphic. It's very modern and
> >> interesting
> >> GUI framework, but it didn't come up to all expectations.
> >
> > I think they would understand it better if it didn't have the windows.
>
> That's a very interesting statement.  How do you imagine this working?
> Do you mean getting rid of all the UI that currently uses SystemWindow
> (Browsers, Debuggers, etc), replacing them with Self-style outliners?
> Or do you just mean making SystemWindows be morphs like any others and
> getting rid of all the special cases around them?

I meant that as soon as developers see things that look like windows (and 
menus, I suppose):

- they have certain expectations as to how they should act and feel, which is 
not unreasonable since they look familiar.

- they associate their previous concepts of "window", "widget", "event loop", 
etc. with the Morphic artifacts that appear to correspond to those concepts.

- they then get frustrated when they run into differences between how these 
familiar user interface elements act (and look) in Squeak and how they act 
and look in the operating system with which they're most familiar.

- they also miss the design philosophy which doesn't differentiate between 
submorphs of the World and submorphs of those morphs. There is no distinction 
in Morphic between a "widget" and a "top level Morph".

I'm not saying that the tools that we have in Morphic that happen to live in 
windows aren't useful. It's just that there's this disconnect between things 
that want to be their own mini-worlds with an idea of focus and locality 
(i.e. windows and their embedded morphs) and things that don't.

I'm also not arguing that Morphic has the best solutions to the problems of 
event routing, layout, drawing, etc.. As someone who has done a fair amount 
of Morphic programming, I feel strongly that we can make Morphic better than 
it is now. However, I'm not sure that a wholesale refactoring of Morphic 
would be worth the time at this point, as there are a couple of important new 
UI systems in the works (Tweak and Croquet), and I also think that the desire 
for a cleaner, more "standard" user interface that includes the elements that 
people are used to is not necessarily best met by Morphic.

As you know, there's lots of stuff in Morphic (and Squeak in general) that is 
a result of its focus on being the platform for EToys. I think that much of 
the current complexity of Morphic is due to design decisions (made under time 
pressure, of course) from EToys (and Alan's various demos) creeping into what 
started out as a much simpler system.

For example, looking at different historical versions we see:

v 1.31 (before EToys):
Morph selectors size 231
Morph withAllSubclasses size 101

v 2.0 (the dawn of EToys):
Morph selectors size 347
Morph withAllSubclasses size 129

v 2.1
Morph selectors size 357
Morph withAllSubclasses size 138

v 2.8
Morph selectors size 540
Morph withAllSubclasses size  269

v 3.0
Morph selectors size  924
Morph withAllSubclasses size   343

v 3.6 full
Morph selectors size   1090
Morph withAllSubclasses size    394

the Squeakland developer's image that I'm working on right now, with m17n and 
Connectors in it:
Morph selectors size  1258
Morph withAllSubclasses size  444

An example of this effect is that there are two different and conflicting 
idioms (well, three if you count my work in Connectors) for associating 
behavior with UI events:

* You can override #mouseDown:, etc. to get the behavior you want
* You can plug the EventHandler by using #on:send:to: (I think that this may 
have been added for triggering EToys scripts from UI events)
* You can override #processEvent:using: for more control over how things are 
handled (I do this in my QHSMMorph which is the basis for my new Connectors)

And there's also one-off variations on this, like (some of the) buttons that 
give you a different way to plug the behavior.

> It would be nice to see some kind of proof of concept of a
> Morphic-without-windows, even a very rough one...

We have one. It's called EToys.

I use Morphic all the time with Connectors and its various morphs and menus 
without ever having to see windows.

-- 
Ned Konz
http://bike-nomad.com/squeak/