[ANN] Bricks v2 now on the swiki
ducasse at iam.unibe.ch
Fri Jun 27 19:03:01 UTC 2003
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
>> * 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
> 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
>> 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
> 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.
>> tblanchard at mac.com wrote:
>>> 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
>>> 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
>>> to help make widgets and painter tools. Email me if you want to
>>> Todd Blanchard
More information about the Squeak-dev