[ANN] Bricks v2 now on the swiki

Stephane Ducasse ducasse at iam.unibe.ch
Fri Jun 27 19:03:01 UTC 2003

Hi todd

please continue, continue, we need a good UI Builder and collection of 

On Friday, June 27, 2003, at 05:30 PM, tblanchard at mac.com wrote:

> 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

More information about the Squeak-dev mailing list