Thanks - I'll answer here and also put them on the swiki.
On Friday, June 27, 2003, at 09:27  AM, Daniel Vainsencher wrote:

> Hi, Todd
>
> I took a look at the page, and it looks pretty cool...
>
> I have a few questions (you might want to make the page explain them
> too):

> * What is your goal? an alternative "morphic for applications"?

The short answer is I want to quickly construct apps with GUIs and it 
should be like hypercard on steroids.  The only code I want to add to UI

It started out that I simply couldn't (and still can't quite) grok how 
to predictably control layout of morphs.
So I set out to try to add a new layout manager - but I could never 
quite get it integrated and the entire UI kept freezing up on me.  The 
api for layout in Morphs is sort of half modernized and very weird.

So I created ProtoMorph - an empty object that steals code from Morph 
to remain compatible, and I started hacking that.
Now if I screwed up the parallel object it didn't take down my image.  
This let me work out how to do the layout.  About the same time I 
wanted to have a visual way of turning on and off the struts and 
springs - so I wrote the layout control as a brick.

Doing the layout control brick I started playing with different looks 
to make it cool and I ran into the very weird idea of BorderedMorph.  
Lots of Morphs derive from Morph, some derive from BorderedMorph and it 
turns on that Morph actually depends on BorderedMorph at some point.  I 
thought this was crazy.  Most morphs, it seems, are going to have a 
background, a border, corner rounding (which is implemented in a really 
odd way and doesn't seem to work with borders), there are highlights or 
washes that you put on things for menu items and such - I figured that 
you could throw most of the really pedestrian drawing out of Morph 
using a decorator kind of pattern.  The Bricks that do drawing do only 
the essential drawing and no more.  For instance, layout control brick 
draws struts and springs, but the rest of it is done by adding 
painters.  The painter idea I got from hearing about Pollack in VW BTW.

> It appears that you're able to do some very useful stuff, like
> automatically saving the description for composed Bricks, and struts 
> and
> springs layout.

Yes.  Right now with Morph assemblies you can turn one into a subclass 
- but I'm not sure how that helps you.  The subclass, when 
instantiated, doesn't give you back what you had.  You can dump the 
morph to a file - but we like to keep things in the image.  I remember 
from working in VisualWorks years ago (version 2.5 it was) that the 
tools often saved resources as class methods that returned some 
bytestream.  I found that really useful.  So I tweaked the morph 
fileout to dump to a bytestream and save it as a string in the method.  
I'd still like to get a version that didn't put up the progress 
indicator but this is good for now.

> * Can you explain the tradeoffs this required? what in Morph did you
> have to give up for this to work?

Nothing much really.  I totally hacked out Morph's layout protocol to 
do struts and springs.  I don't miss it because I could never figure 
out how to get it to do what I wanted.  For the couple of morphs that I 
converted to bricks, basically I just simplified the drawing code, and 
and I hacked out a lot of the drawing options (ie, the borderstyle, 
fillstyle, hilight flags or whatever - all that state is contained in 
the painters.

> * could this work be applied to general morphs?

Absolutely yes in theory. But I've locked up more images than you can 
imagine so I'm not in a hurry to try it.
Instead, I'm using Morph as a parts bin and converting Morphs to bricks 
by changing their superclass and cleaning them up.

> * Could something be written that explores a Morphic SystemWindow and
> produces a similar window with most of the functionality in Bricks?

I don't see why not.  I don't have a system window kind of thing yet - 
I still rely on Halos to resize morphs yet but I can see getting there. 
  I've done some window trials that look and act kind of like Mac aqua 
windows.  There's more to do but it just programming and more 
programming.

The biggest problem I'm dealing with is event delivery.  Morphic's 
event delivery is too complicated for the programmer to use IMHO.  You 
can't just implement a handler for an event - you also have to make 
sure that you set yourself as a handlerFor, then return true on 
handlesSomeEvent, then you'll get the event.  Most event frameworks 
just deliver the event to the innermost element and the default handler 
redelivers the event to the owner.   I'm doing some of that in Bricks 
and its working pretty well - but there is still a lot of weirdness in 
event delivery.

An example is button hit tracking.  I spent 3 days on the checkbox 
brick's behavior.  The usual behavior for a button is to hilight  on 
mouse down, then track the mouse while its down unhilighting when the 
mouse leaves and rehilighting when it reenters.  If the mouseUp happens 
in the element, then you deliver a click.  Morph's event handling 
change makes this really hard to implement and I had to make some small 
changes to MouseClickState to make it work.  There is more to do but 
you have to move gingerly because messing with Morph's event handling 
code can freeze your image.



>
> Daniel
>
> tblanchard at mac.com wrote:
>> http://minnow.cc.gatech.edu/squeak/3186
>>
>> I've made some progress and there's a screen shot there now.  You can
>> download a sar file and try it out.
>>
>> I'm interested in getting some volunteers to work on this.  I'd like 
>> to
>> make it so UI creation is all about putting painters and scripts
>> together.  I think I'm at a decent point where other people could 
>> start
>> to help make widgets and painter tools.  Email me if you want to help.
>>
>> Todd Blanchard
>