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 <[email protected]>: >> 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 <[email protected]> >>> 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 >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
