[Pharo-project] A new GUI visual designer

Igor Stasenko siguctua at gmail.com
Mon Feb 14 10:28:31 CET 2011


On 14 February 2011 09:59, Sven Van Caekenberghe <sven at beta9.be> wrote:
> Hi Göran,
>
> On 14 Feb 2011, at 00:18, Göran Krampe wrote:
>
>> 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 :)
>
> Excellent summary/writeup !
>
>> 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.
>
> Tirade looks cool, very nice idea, simple and powerful. Nice name too.
>
> Some questions:
>
> - don't you need a more formal (BNF) spec (I like the drawings on the http://json.org/ site) ?
> - there does not seem to be a way to deal with non-ascii strings like 'Göran', shouldn't there be something like JSON escapes ?

No. Wake up. Its 2011 outside. Use unicode encodings (like UTF-8) for
reading/writing source streams.
Just don't use ascii, then you won't need to escape non-ascii characters. :)

> - should there not be some kind of convention to note the expected reader (in a comment as meta data maybe) ?
> - has this since 2009 been used anywhere ?
> - how about inter Smalltalk interoperability ?
>
> Sven
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-project mailing list