[Pharo-project] A new GUI visual designer

Craig Latta craig at netjam.org
Fri Feb 18 02:04:20 CET 2011

Hi Göran--

> Thinking about this a bit more I realize one interesting aspect:
> Your stuff is basically low level serialization support - right?

     It is, but what makes it interesting is that it's *interactive*
serialization; the producing and consuming systems interact.
Traditionally, you serialize to a file, and at the time the consuming
system reads it, the producing system is long gone. The consumer can't
ask the producer anything about it if finds something confusing, and the
producer can't take any information about the consumer into account when
creating the bits.

     Speaking of recipes, imagine following a recipe from a cookbook.
You might wonder if you can leave some ingredient out (because you
forgot to go the store), but you're on your own figuring that out. All
you have is the recipe. But if the author of the recipe were there with
you, telling you what to do, you could just ask. And the author might
not even bother mentioning the missing ingredient, because he can
already see when you start that you don't have it.

     It's this sort of synchronization that Naiad (Spoon's module
system) supports. It's important when transferring individual method
literals, entire methods, and entire modules. It's all messages going
across the wire between producer and consumer, and their precise content
may vary significantly from one consumer to another. Expecting one set
of bits to convey the correct thing to all consumers, in a system as
dynamic as Smalltalk, always struck as me a bit crazy. :)

> So... it all boils down to what kind of object model you pick. Now...
> come to think of it - readable and editable? Not sure how you mean
> there...

     I meant it in the sense that I thought you did... the way I'd store
GUI information is even more readable than viewspec arrays or XML
because it's just the original objects from which we derived the
viewspecs and XML. It's more editable for the same reason; we can use
the same powerful inspectors and browsers that we used during development.

> ...counting the designer tool as the editor is kinda cheating :)

     Hey, if it's useful, why not? :)

> One nice way to make a GUI description to be very robust against
> change is to let it be the representation of "a sequence of commands
> aimed at a builder API". Thus, the actual UI framework can change all
> it wants, as long as the builder API still works.
> So, if your object model is such a "command sequence" then I agree, it
> would be as robust as the same thing in Tirade. But... if your model
> is the actual built UI then I don't agree that it is as robust -
> supporting "migration" from one object model to a new one is kinda
> complex.

     Well, builder APIs can change, too. But sure, I'm not attached to
any particular GUI object model, or style of model (declarative or
otherwise). I do think, though, that using the actual built UI becomes
an interesting option when you have live synchronization. I view the
complexity as similar to writing correct "postCopy" methods (not too
bad). You could ask a UI object to spit out builder commands, for
example, as I suggested in an earlier message. Builder commands could be
an exchange format, used occasionally when necessary.


Craig Latta
+31  06 2757 7177
+ 1 415  287 3547

More information about the Pharo-project mailing list