BTW, did you have a chance to look into MVC codes, Do you have anything to complain ?
I heard tons of bad thing about Morphic but not much about MVC.
Is it because not many people are using MVC or because MVC code is of high quality ?
MVC is the first complex GUI ever so it's very old and its look and architecture can't gratify all demands on a modern user interface. But it's well-ripened, stable, compact and unpretentious. People know its limitations and when they have to work with it, they don't castigate it so much. And - as you say - they use it sporadicly now. MVC doesn't have better architecture than Morphic but its implementation is cleaner.
Morphic is much more complex. You can't compare it to MVC because it has the other purposes. Morphic is easier to use for a developer and very flexible.
IMHO developers are frustrated by Morphic. It's very modern and interesting GUI framework, but it didn't come up to all expectations.
Firstly it doesn't look conventional, it doesn't contain implicitly standard GUI components like combo-boxes etc. Without mouse support you can do absolutely nothing. It has strange windows management. Inactive windows disable all its components (look at Zurgle to see it). You can't switch between submorphs using Tab key etc. But you can tell it about MVC too.
One of the most strange features of Morphic and MVC is the single world cycle. One long computation can make whole GUI unusable. It's not a feature of Squeak's process scheduler. I have created an experimental window manager with separated message passing cycles, all GUI messages were sent through shared queues and it has worked perfectly.
Pavel
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.
Firstly it doesn't look conventional, it doesn't contain implicitly standard GUI components like combo-boxes etc.
Is there anything in Morphic that would keep you from building one easily?
Without mouse support you can do absolutely nothing.
What mouse support is missing?
It has strange windows management.
The windows in Morphic are not really the primary objects like they are in most UI systems. As far as I can tell, they were made so that the existing tools in the MVC environment could be ported quickly to Morphic. That's the origin of all the Pluggable* components; you will see that there are pairs of them with similar APIs for MVC and Morphic.
Inactive windows disable all its components (look at Zurgle to see it).
Zurgle has, as I recall, its own idea of focus and window activity.
You can't switch between submorphs using Tab key etc.
We have had this working from time to time.
One of the most strange features of Morphic and MVC is the single world cycle. One long computation can make whole GUI unusable.
How is this different from what was done in Mac OS 7 or Windows 3.1? I recall many applications that would make the whole GUI unusable by doing just what you describe in response to a UI action.
Later operating systems tended to assign a separate thread per application; they could easily maintain the behavior of the rest of the system by using message queues.
In fact, if you look at Squeak as a single application (which it is, despite the windows) ours is a fairly typical architecture. Events come up from the VM and are dispatched in a single loop.
There is enough shared state in Squeak that having multiple GUI processes would require quite a bit of work for little benefit if you wanted anything more interesting than a "windowing system". I want to have live objects in my world, and I don't particularly want them confined exclusively to windows. As soon as morphs need to talk to each other (which is not generally the case with windows but is essential for pretty much everything else we do with Morphic) you wouldn't be able to call the methods of other morphs directly any more, which would require a number of changes. You'd probably have to distinguish between top-level morphs and other morphs; the top-level ones would have their own message queue, etc. But then there would be a difference between (say) a RectangleMorph loose in the World and one that was embedded in a window or other top-level container: the one in the window could have its methods called directly and would be a "second class citizen" intended only for embedding, and the one loose in the World would not be able to have its methods called directly. This would be like the distinction between "widgets" and "windows" in many windowing systems.
I agree that mixing models has led to strangeness; the attempts to make the SystemWindows behave more and more like operating-system windows despite their existence alongside other non-window morphs have not always resulted in consistent behavior. But at least it got the MVC tools working in Morphic. One example of this strangeness is the "topmost window" concept which is completely at odds with the existing Morphic layering; another is the concept of "window focus". Morphic itself doesn't have focus other than the halos, but the concept was added to the windows. So if you have a mixture of windows and non-windows in the world, you will sometimes see situations where the Z-ordering will suddenly be reorganized (for instance, after you enter a new project or save the image).
As it is now, it's quite simple to put long-running computations in background threads; you just don't let the background threads call methods directly on Morphs. We have addDeferredUIMessage: to queue up action from the background threads for later execution in the UI thread during the next window cycle.
It's not a feature of Squeak's process scheduler. I have created an experimental window manager with separated message passing cycles, all GUI messages were sent through shared queues and it has worked perfectly.
But Squeak isn't a window manager (despite the things that look somewhat like UI windows), and the things in the World (windows or other morphs) aren't separate applications. Or, looked at another way, every morph is a separate application whether or not it is a top-level morph (they each have their own step methods), but then there is still no distinction between top-level morphs (well, other than the World itself) and embedded morphs. Top-level morphs are just submorphs of the World, and a lowly StringMorph or RectangleMorph deep in a construction somewhere inside a window is no less live than the window itself.
If you wanted to make a UI in the style you describe -- merely concerned with standard kinds of windows and UI elements inside them -- many of the issues around intra-Morph communication would not be a problem. But you're missing the point, I think; Morphic was not intended (as far as I know) as a windowing system. As you point out, the MVC system is much closer to this model, with its controllers that are associated with things that look like windows on the desktop.
Whether Morphic is the right design for the kinds of things *you* want to build, I don't know. Maybe it isn't a good fit.
However, there is nothing that I can think of in Squeak that would prevent you from writing a completely different UI system fairly easily. In fact, there have been several of these already: the Parks PDA that John Maloney did had one, his Scratch system has another, Andreas' Tweak system has another, Croquet has another, and so on.
The co-existence of MVC and Morphic shows that it is possible to make a completely different UI model and still re-use the basic UI system (events, canvases, invalidation, etc.). We could probably make the work required to add different kinds of Projects/Worlds a bit easier, though; there's a fair amount of code at the project level that assumes that projects are either MVC or Morphic.
On Monday 30 August 2004 7:02 am, I wrote:
One example of this strangeness is the "topmost window" concept which is completely at odds with the existing Morphic layering; another is the concept of "window focus". Morphic itself doesn't have focus other than the halos, but the concept was added to the windows.
Actually, there is mouse and keyboard focus. I haven't had my coffee yet.
Firstly it doesn't look conventional, it doesn't contain implicitly standard GUI components like combo-boxes etc.
Is there anything in Morphic that would keep you from building one easily?
Nothing but... When I noticed this fact in one of my articles, the reaction of many readers was simple: "I like never-ending opportunities...".
Without mouse support you can do absolutely nothing.
What mouse support is missing?
You cannot control Morphic only using keyboard.
Your message is very nice introduction to the philosophy of Morphic. I know it very well and I agree with you. I use the same arguments like you when I have to advocate Morphic and Squeak. I like Morphic but I have to say that it's hard to use in standard applications now.
Some loose ends are annoying. For example, I create a morph. It has to behave like a system window (through overlapping) but the hierarchy of system windows is protected by a SystemWindow metaclass interface - there isn't any accessing method (maybe in newest versions is).
But Morphic has great potential...
Pavel
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?
It would be nice to see some kind of proof of concept of a Morphic-without-windows, even a very rough one...
Avi
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 wrote:
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.
There is also Dan Ingalls components framework. There used to be a demo for it back in 2.x and maybe early 3.x. I though that was a quite good model for a dynamic changeable gui.
Karl
On 30/08/04 15:15, "Karl Ramberg" karl.ramberg@chello.se wrote:
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.
There is also Dan Ingalls components framework. There used to be a demo for it back in 2.x and maybe early 3.x. I though that was a quite good model for a dynamic changeable gui.
Karl
Karl, here is Fabrik. Can load on 3.7 but don't works as in 3.0. Maybe Dan remember his promise of almost a year and have a new version/ examples.
Edgar
Hi Ned,
[SNIP]
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),
IMHO, the factoring should have done before Croquet and Tweak and Scratch were created.
It should have been done when there was talk about folding Stable Squeak into main stream Squeak. (How much time and efforts wasted in Stable Squeak ?)
It should have been done when Henrik module system was incorporated into main stream Squeak. (How much time and efforts was wasted)
"A More Inclusive Community-Based Model for Squeak Development" http://bike-nomad.com/squeak/community2.html
"Please note that I have tried not to talk about technical solutions to problems. I don't think that the problems we're having are primarily because of a lack of appropriate tools or system design.
Rather, I think that we have ignored a number of important social factors in the design of the community"
IMHO, the problems are not only technical and social, but also psychological and "political".
It may be a bit late now but it is still better than never.
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.
You might want to review this opinion after Morphic is factored, if that ever happens.
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.
How "eloquently" said !
This is understandable. After all, Apple and Disney were incorporated for profit and Alan has his own agenda.
After SqC let go of Disney, there was no more time pressure and was the focus still on eToys ?
Why Croquet while eToys/Morphic is still a mess ?
Why Croquet while cheering the modularizing efforts ?
Why adding more storeys on top of a shaking foundation ?
Why not factoring Morphic ?
Why not removing the dead bodies rotten inside Squeak ?
Was Squeak/Morphic a success ?
Maybe yes, a catastrophic success !
Why the heck I am sitting here and typing these silly words !
[SNIP]
On Monday 30 August 2004 8:34 am, Avi Bryant wrote:
It would be nice to see some kind of proof of concept of a Morphic-without-windows, even a very rough one...
If you think about what windows do for us, you'll see that there have to be other ways to do what they do.
What overlapping windows do (off the top of my head):
* they provide single grabbable object that acts as a container and may be moved or overlapped with others to save pixels and limit what you have to look at at any instant
* they bundle several related UI elements together and often let you resize the areas that those elements occupy
This isn't really very much.
We've seen many environments that don't use overlapping windows at all, ranging from the very task specific (CAD programs, etc.) to different user interface models (like the visual languages) to all-text environments like some versions of Emacs.
If the problem is just being able to re-use pixels and organize what you see at any instant, then all we need is some facile way to remember the various arrangements of things that we've constructed, rearranged, or had pre-constructed.
Instead of having to stick things in windows (or other containers), if there was a more general way to specify the arrangement constraints of UI elements (along with wiring up the events, etc.) then that could be used both to glue UI elements together into tools and to glue those tools into task-oriented snapshots of a workbench or desktop configuration. Windows themselves aren't needed for this purpose, though it is nice to have common UI elements for resizing and grabbing.
The ownership relationship in Morphic is an example of a global policy for such constraints that mostly seems to work well but can be limiting sometimes. I just added the ability for Connectors to attach to submorphs; this introduced the necessity to add new accessors to EToys so that the embedded pins and their owners could talk with each other.
Ned Konz wrote: Instead of having to stick things in windows (or other containers), if there
was a more general way to specify the arrangement constraints of UI elements (along with wiring up the events, etc.) then that could be used both to glue UI elements together into tools and to glue those tools into task-oriented snapshots of a workbench or desktop configuration. Windows themselves aren't needed for this purpose, though it is nice to have common UI elements for resizing and grabbing.
I played with the Components framework yesterday, and I had a fun time trying to make a FileList kind of tool. I got it working after a while and all it took was two lines of code.
Karl
Ned Konz wrote:
How is this different from what was done in Mac OS 7 or Windows 3.1? I recall many applications that would make the whole GUI unusable by doing just what you describe in response to a UI action.
This reminds me one funny situation when I was working with Mac OS in version 9 even. I was wondering when it takes such a long time for Microsoft Explorer to download a relatively short file. Then I found out it was simply not doing the job while I was doing other things with GUI. Best solution to get the file quickly was to open a web page, starting to read it and not touching GUI much :) In Squeak we're not even there, while downloading something everything is stuck. But this is rather up to application or some system layer design.
In fact, if you look at Squeak as a single application (which it is, despite the windows) ours is a fairly typical architecture. Events come up from the VM and are dispatched in a single loop.
I have a project in my papers which heavily uses touchscreen and is not connected with using windows as overlapping areas. In this area I think Morphic can be a real benefit.
If you wanted to make a UI in the style you describe -- merely concerned with standard kinds of windows and UI elements inside them -- many of the issues around intra-Morph communication would not be a problem. But you're missing the point, I think; Morphic was not intended (as far as I know) as a windowing system. As you point out, the MVC system is much closer to this model, with its controllers that are associated with things that look like windows on the desktop.
Looks like we should put warning to newcomers - objects that look like windows might not be what they are :) I hope I don't touch anybody smiling over here. Working paradigm based on windows and desktop comes from real situation when people in before-computer ages were used to work with papers on their desktops. Now if you look how different every application (in sense of BFAV, Celeste, IRC client) looks from point of view of user how do you feel about it? Almost everyone working with computer today is use to have some floating windows. Even as a developer I use to have window here and window there. In contrast when I work remotely on Linux machine I use to have SSH terminal with Emacs-like environment. When working with Squeak/Morphic I feel like being in between those two.
On Thursday 02 September 2004 3:19 am, Kamil Kukura wrote:
Looks like we should put warning to newcomers - objects that look like windows might not be what they are :) I hope I don't touch anybody smiling over here. Working paradigm based on windows and desktop comes from real situation when people in before-computer ages were used to work with papers on their desktops. Now if you look how different every application (in sense of BFAV, Celeste, IRC client) looks from point of view of user how do you feel about it?
Actually, if you look at the Squeak SystemWindows as being the equivalent of the sub-windows in the old Windows MDI style, they're not much different in behavior.
On Thu, Sep 02, 2004 at 11:03:15AM -0700, Ned Konz wrote:
Actually, if you look at the Squeak SystemWindows as being the equivalent of the sub-windows in the old Windows MDI style, they're not much different in behavior.
True enough. Although the observation amounts to damning with faint praise.
Dave
squeak-dev@lists.squeakfoundation.org
-
Avi Bryant -
David T. Lewis -
Kamil Kukura -
Karl Ramberg -
Lic. Edgar J. De Cleene -
Ned Konz -
Pavel Krivanek -
SmallSqueak