Removing Morphic

Keith Hodges keith_hodges at
Sat Oct 21 16:30:23 UTC 2006

In my day job I get a lot of time to think, so today I was thinking 
about  this thread.

It appears to me that all of the current options represent forks in some 
way. While there are a number of new initiatives (understandably) being 
developed to serve their own goals, in their own islands (if you pardon 
the pun), there does not appear to be an implementation or even an 
envisioned solution that 'serves' the community in such a way as to 
promote cohesion and  integration. So I began to think about how one 
might achieve this.

Some extremely talented people have spent a lot of time improving 
morphic. Others are developing frameworks on top of morphic. It would be
a great shame, perhaps even insulting to even consider 'just throwing it 

The needs of the community includes a wide range of applications. There 
are those who have their multi-cpu 3D accelerated graphics processors, 
and those for whom raw CPU power is not available. (On my PC 3.9 
typically gives almost a 2 second pause before responding to any mouse 
click in any tool).

Building developer tools in all of these different frameworks is far 
from simple.

Running the developer tools in the same UI framework as the code being 
developed leads to some problems in debugging. (ref. Brick's write up) 
This slows development and probably puts people off developing those 
frameworks further.


A new gui framework from the ground up, lets call it WIZ, simply because 
I cant think of anything else to call it right now. I think that the 
ground is ready for this, since projects such as Spoon, represent 
potentially new ground anyway, and it may be time to apply some of the 
lessons learnt over the last 20 years. Rather than apply those lessons 
to provide more functionality with less efficiency, aim to  promote a 
'less is more' philosophy.

This framework should be written with the primary goal of being utterly 
simple to develop boring (for boring read business) applications, and 
developer tools.

A second goal would be the requirement to be efficient and fast. i.e. No 
need for  graphical rotation. Rectangular clip regions only for fast 
screen redraws. Simple heirarchical components, with an inside-out event 
model, and a simple outside-in layout model.

For those that like skins, or platform specific look and feel like. 
Components should be created via factory patterns (or some equivalent), 
and I figure that there may be scope for applying skins as a mix-in, and 
therefore enabling skin switching by switching the current skin-trait.

Spoon potentially supports multiple displays, and recent vms potentially 
support multiple host windows. Therefore should be possible to run two 
frameworks in parallel.

Morphic can have a WIZWindowMorph which hosts a WIZWindow component. 
Thus all of the WIZ developer tools will be available within morphic. 
The same goes for tweak. Each GUI framework fork can move forward 
without being hindered by a lack of developer tool support.

Using WIZ as the primary UI, then may make it possible to decouple 
Morphic from the developer tools. WIZ could be used for debugging 
Morphic. Morphic need not have developer tools at all. (of course 
Morphic can be used for debugging WIZ). In this way WIZ serves the other 
frameworks and their developers.

The base architecture of WIZ being designed to be embedded in other 
frameworks should therefore naturally be able to support native windows, 
if not native widgets. There is of course nothing stopping anyone using 
native widgets if they want to.

WIZ is likely to exist in a distributed world. Some thought should go in 
the architecture design so as to be appropriate for remote use. I.e. A 
wiz viewer onto a headless seaside image should be a far better solution 
than VNC. The notion of a WIZ thin client could be a relatively sensible 
solution to distributed business apps in contrast to the current state 
of the web. (not forgetting the WIZ Firefox plug in)

WIZ could be an adaptation of the current MVC, I would like to consider 
attempting to use MVP. (would someone going to the London meet like to 
ask Andy Bower if he might consider releasing Dolphin's GUI code under 
MIT licence? Now that would be cool)

This email represents a brainstorm, it in no way reflects my own 
knowledge and ability to actually implement such a framework. However I 
think that this kind of visionary dialog might eventually provide an 
avenue that the whole community can focus upon and feel happy with 

what do you think?

best regards


Send instant messages to your online friends 

More information about the Squeak-dev mailing list