[Pharo-project] A new GUI visual designer

Göran Krampe goran at krampe.se
Mon Feb 14 00:18:21 CET 2011


Hi!

Sorry, this post turned out long. But hopefully interesting anyway.

On 02/13/2011 06:36 PM, Schwab,Wilhelm K wrote:
> You cite an example very similar to what Dolphin does, and we could do with SIXX.
 > Dolphin serializes things not to avoid the image but to allow packaging.
 > SIXX could do the same for us.
[SNIP]

 > If we had something that could read and rewrite Smalltalk code that 
is truly independent
 > of WB, then class methods would be nice way to store GUI designs.
>
> Bill

Just wanted to chip in here - IMHO there is a loooong history when it 
comes to how to "save" UIs. We have seen (and in many different 
programming languages) various ways through the years:

- Build them with code each time we want them
	Pros:	Resilient against framework/library changes
		Very readable and editable
		Easy to "store" in the language (just save as a method)
	Cons:	Very hard to use as a "save format"
		Has too much freedom if we hand edit it

I actually favor the above since I normally dislike UI Designer tools 
:). But I can of course see the value of a really good UI designer (WB 
Pro is one of the best I have ever used, and the one in VisualAge was 
also superb).

- Save them in "dumb" data structures (like VW specs)
	Pros:	A bit resilient since it relies on a builder, but not as good as 
code because it is just dumb data
		Similar easy to store in the language
	Cons:	Not readable and editable
	
VW has used this for a long time and it is indeed pretty slick since you 
just "store" it in a method. That is one very nice characteristic, and 
if you have good options to dig into the builder after it has read the 
spec - then having the spec be "non readable/editable" is not that 
painful. But still, it is a bit of a serialization hack and ... doesn't 
feel quite right.


- Save them in a more advanced (than an Array) non Smalltalk langauge 
like XML
	Pros:	Quite resilient against framework/library changes, if grammar is 
made to be declarative in style
		Easy to use as "save format"
	Cons:	Get's complex and icky
		Not so easy to "store" in language (a String literal?)
		Not so readable and editable

IMHO using XML is "nice" (well...) for inter system and inter language 
communications/interchange. But realistically, how much interplay can we 
expect when we are talking about Morphic UIs? AFAIK the rest of the 
world haven't been able to gather around a single format either. If 
there indeed was a format that all the Gtk/Qts and whatnots out there 
used - then by all means. But is there?


- Serialize (in binary or whatever language like XML etc) them as they 
are in their object form and deserialize to instantiate
	Pros:	Simple as save format, just smack it out
	Cons:	Not resilient against framework/library changes, in fact very brittle
		Not readable nor editable
		Not so easy to "store" in langauge (ByteArray? String literal?

Serialization (as in "storing the object model exactly as it is") IMO 
almost only has drawbacks. It is very brittle when systems change and it 
is not readable nor editable etc. I just don't like it at all :)



Ok, sooo... not sure if I made the Pros/Cons clear enough to be 
understood here. Anyway, in my quest earlier to build Deltas and 
Deltastreams I ended up investigating "formats" and then I created Tirade:

	http://goran.krampe.se/blog/Squeak/Tirade.rdoc
	http://goran.krampe.se/blog/Squeak/Tirade2.rdoc
	http://goran.krampe.se/blog/Squeak/Tirade3.rdoc

(sorry for lack of nice CSS there)

NOTE: Since those articles I have simplified it a bit - I scratched the 
complicated "stack" logic around figuring out the receiver.

Anyway, Tirade is in short a very long cascade that only allows 
arguments in literal forms. So basically Tirade doesn't serialize 
objects - it serializes a *sequence of messages*. And then when we 
"deserialize it" we replay those messages onto a receiver.

Thus, in syntax it is very Squeakish - it even uses the same number 
parser etc as the Compiler does. But it is a very restricted subset of 
Smalltalk which makes it fast and secure.

So, given the Pros/Cons above, let's see how Tirade would fit:

* Easy to read and edit: yes, it looks like Smalltalk, but without a 
receiver to the left.

* Easy to store in a method: yes, quite simple, the easiest way may be 
to save it as "Smalltalk" like this:

tiradeOn: recorder
	"Create Tirade by sending messages to a Tirade recorder."
	recorder message1; message2; message3

In that way you can still use senders/implementors etc of the message 
selectors.

* Easy to store outside of the language: yes, trivial, and fast to write 
and read

* Very resilient against framework/library changes if we use a 
declarative style.



regards, Göran




More information about the Pharo-project mailing list