[Pharo-project] A new GUI visual designer

Göran Krampe goran at krampe.se
Wed Feb 16 11:52:11 CET 2011

On 02/14/2011 11:14 AM, Craig Latta wrote:
>       This scheme is readable, editable, easy to store, and amenable to
> framework change (the four things you were after).

Thinking about this a bit more I realize one interesting aspect:

Your stuff is basically low level serialization support - right? 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, 
counting the designer tool as the editor is kinda cheating :)

But that was not what I was thinking about - you say that it is 
"amenable to framework change", and I just wrote that serialization 
generally is really bad for that.

Thinking more closely, as I said, it boils down to the object model. On 
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.

Anyway, I was not really meaning to argue against Spoon - my main point 
was that representing a UI as a "recipe" for constructing it is probably 
the most robust way to do it. And isn't VW specs actually something like 

And the corollary is that representing UIs as "snapshots" of them when 
they are constructed (using serialization schemes) is IMHO not at all as 

regards, Göran

More information about the Pharo-project mailing list