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. I favor the idea of SIXX more to avoid falling into a trap of being subliminally influenced by (aka stealing from) Window Builder than because I think it is the correct thing to do. 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 ________________________________________ From: [email protected] [[email protected]] On Behalf Of Richard Durr [[email protected]] Sent: Sunday, February 13, 2011 11:56 AM To: [email protected] Subject: Re: [Pharo-project] A new GUI visual designer Just a comment: :) The Interface Builder of Nextstep and Mac OS X – a closely Smalltalk-related and inspired system – creates the objects making up the user interface (it instantiates them) and then saves the state of everything into a nib/xib file (binary/xml) using the general object-persistency mechanism of Cocoa (NSKeyedArchiver). This file is then loaded when the application in question starts, all the freeze-dried objects in the UI-file are revived (awakened – not created) and then loaded into the object space of the app. This reminds me of the way, the Smalltalk Image works – except that the image stores the whole application object space where the nib/xib only stores the objects the interface is composed of. With Morphic there even exists an easy way to compose an interface with using original objects directly like or better than Interface Builder. But instead of using the image as a storage mechanism for the instantiated objects of a morphic-designed interface we are stuck with the textual distribution mechanism and discussing how we can for example use xml to do that. That is ironic, I think ^^ -- Sent from my DynaBook.
