The manipulation and construction that Torsten is currently pursuing is useful and independent of the "ultimate" format. It should not be hard to change the storage/representation format: a visitor walks the tree and invokes the right i/o broker. The brokers could become more sophisticated as generality is needed. In fact, this can be added at any time ... so for his needs right now what is easiest? Ultimately, I would strongly encourage making it more abstract (not referencing concrete morphs) -- to address what Stef mentioned. Of course, that begs the question of how to map unique morphs that have no analogs in other windowing systems. Translation problem example: I have a ClsQuoteTickerMorph (or something like that) that inherits straight off of StringMorph, and it knows how to update itself every two minutes, and it requires net access to work. -Cam On Jul 21, 2009, at 12:28 PM, Igor Stasenko wrote:
This is way better than having a methods carrying a multi-kilobyte long bytearray, but still not perfect.
Why just don't 'serialize' the morph as a code which builds it?
buildMyMorph
| myMorph | myMorph := MyMorph new. myMorph layout: blablahblah.. myMorph label: blabla... ... ^ myMorph
2009/7/21 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Yes something like that. Use a system that we can hack and modify (have a look at the VW windowspec)
this way your builder to build morphic but also something else too.
windowSpec "UIPainter new openOnClass: self andSelector: #windowSpec"
<resource: #canvas> ^#(#{UI.FullSpec} #window: #(#{UI.WindowSpec} #properties: #(#{UI.PropertyListDictionary} #sizeType #specifiedSize #positionType #screenCenter #openType #advanced ) #label: #(#{Kernel.UserMessage} #key: #aboutVisualWorks #defaultString: 'About Visual Works' #catalogID: #labels) #min: #(#{Core.Point} 20 20 ) #max: #(#{Core.Point} 1024 768 ) #bounds: #(#{Graphics.Rectangle} 512 384 992 704 ) ) #component: #(#{UI.SpecCollection} #collection: #( #(#{UI.TabControlSpec} #layout: #(#{Graphics.LayoutFrame} 10 0 10 0 -10 1 -40 1 ) #name: #tabs #model: #tabListHolder #labels: #() ) #(#{UI.ActionButtonSpec} #layout: #(#{Graphics.LayoutFrame} -90 1 -35 1 -10 1 -10 1 ) #name: #ok #model: #accept #label: #(#{Kernel.UserMessage} #key: #OK #defaultString: 'OK' #catalogID: #labels) #isDefault: true #defaultable: true ) ) ) )
Stef
On Jul 21, 2009, at 2:58 AM, Mariano Martinez Peck wrote:
On Mon, Jul 20, 2009 at 7:15 PM, nullPointer <epicfan@gmail.com> wrote:
Excuse me for my poor english.
I´m developing a GUI Builder for Pharo -> http://www.youtube.com/watch?v=CHbc1t83fEI
One of my problems is the way of persist a morph.Now i use the same way for create a Morph than message #saveOnFile but not saving in a external file else in array of bytes returned for a #spec message.
I would know if morphic allow or exists another way of persistence more readable and fast. A complex morph serialized of that way is too slow in load.
Perhaps you can use another serializer. Here a some: http://www.seaside.st/documentation/persistence
For example, http://www.seaside.st/documentation/persistence#230290016 or http://www.seaside.st/documentation/persistence#40827471
Your project seems very interesting, tough.
Best,
Mariano
Regards. -- View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3292117.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project