[Pharo-project] Persist a morph in a message.
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. 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.
2009/7/21 nullPointer <epicfan@gmail.com>:
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.
Just a guess: maybe it is better to persist a morph(s) as is - as original objects - just keep them somewhere in classvars. Then to create a new view of it, just do a #deepCopy. P.S. counter asString don't needs to be enclosed in parenthesis.
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
-- Best regards, Igor Stasenko AKA sig.
Just a guess: maybe it is better to persist a morph(s) as is - as original objects - just keep them somewhere in classvars. Then to create a new view of it, just do a #deepCopy.
Perhaps could be a combined solution. Persist the morph in a method, but only load one time, if class var is nothing. Then in the next times send #deepCopy to prototype morph . That could be a solution for the velocity :) I believe than EasyMorphicGUI works of that way too. Regards. -- View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3295437.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
2009/7/21 nullPointer <epicfan@gmail.com>:
Just a guess: maybe it is better to persist a morph(s) as is - as original objects - just keep them somewhere in classvars. Then to create a new view of it, just do a #deepCopy.
Perhaps could be a combined solution. Persist the morph in a method, but only load one time, if class var is nothing. Then in the next times send #deepCopy to prototype morph . That could be a solution for the velocity :) I believe than EasyMorphicGUI works of that way too.
Regards.
Any reasons to stay anonymous? Hey, we don't/can't harm you in any way :) Instead, i think that it would be not only me, who could say, that we would really like to help you with that.
-- View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3295437.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
-- Best regards, Igor Stasenko AKA sig.
Perhaps Stef is "moonlighting" under an alias... ? (He replied to himself for cover.) -cam On Jul 21, 2009, at 5:16 PM, Igor Stasenko wrote:
2009/7/21 nullPointer <epicfan@gmail.com>:
Just a guess: maybe it is better to persist a morph(s) as is - as original objects - just keep them somewhere in classvars. Then to create a new view of it, just do a #deepCopy.
Perhaps could be a combined solution. Persist the morph in a method, but only load one time, if class var is nothing. Then in the next times send #deepCopy to prototype morph . That could be a solution for the velocity :) I believe than EasyMorphicGUI works of that way too.
Regards.
Any reasons to stay anonymous? Hey, we don't/can't harm you in any way :) Instead, i think that it would be not only me, who could say, that we would really like to help you with that.
2009/7/22 Cameron Sanders <camsanders01@roadrunner.com>:
Perhaps Stef is "moonlighting" under an alias... ? (He replied to himself for cover.)
Then you are 'moonlighting' under a 'Sherlock Holmes' alias :)
-cam
On Jul 21, 2009, at 5:16 PM, Igor Stasenko wrote:
2009/7/21 nullPointer <epicfan@gmail.com>:
Just a guess: maybe it is better to persist a morph(s) as is - as original objects - just keep them somewhere in classvars. Then to create a new view of it, just do a #deepCopy.
Perhaps could be a combined solution. Persist the morph in a method, but only load one time, if class var is nothing. Then in the next times send #deepCopy to prototype morph . That could be a solution for the velocity :) I believe than EasyMorphicGUI works of that way too.
Regards.
Any reasons to stay anonymous? Hey, we don't/can't harm you in any way :) Instead, i think that it would be not only me, who could say, that we would really like to help you with that.
_______________________________________________ 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.
You are better than I suspected, Watson! On Jul 21, 2009, at 8:16 PM, Igor Stasenko wrote:
2009/7/22 Cameron Sanders <camsanders01@roadrunner.com>:
Perhaps Stef is "moonlighting" under an alias... ? (He replied to himself for cover.)
Then you are 'moonlighting' under a 'Sherlock Holmes' alias :)
-cam
On Jul 21, 2009, at 5:16 PM, Igor Stasenko wrote:
2009/7/21 nullPointer <epicfan@gmail.com>:
Just a guess: maybe it is better to persist a morph(s) as is - as original objects - just keep them somewhere in classvars. Then to create a new view of it, just do a #deepCopy.
Perhaps could be a combined solution. Persist the morph in a method, but only load one time, if class var is nothing. Then in the next times send #deepCopy to prototype morph . That could be a solution for the velocity :) I believe than EasyMorphicGUI works of that way too.
Regards.
Any reasons to stay anonymous? Hey, we don't/can't harm you in any way :) Instead, i think that it would be not only me, who could say, that we would really like to help you with that.
_______________________________________________ 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
I would loved to have the time to do that but no :) Stef On Jul 22, 2009, at 1:53 AM, Cameron Sanders wrote:
Perhaps Stef is "moonlighting" under an alias... ? (He replied to himself for cover.)
-cam
On Jul 21, 2009, at 5:16 PM, Igor Stasenko wrote:
2009/7/21 nullPointer <epicfan@gmail.com>:
Just a guess: maybe it is better to persist a morph(s) as is - as original objects - just keep them somewhere in classvars. Then to create a new view of it, just do a #deepCopy.
Perhaps could be a combined solution. Persist the morph in a method, but only load one time, if class var is nothing. Then in the next times send #deepCopy to prototype morph . That could be a solution for the velocity :) I believe than EasyMorphicGUI works of that way too.
Regards.
Any reasons to stay anonymous? Hey, we don't/can't harm you in any way :) Instead, i think that it would be not only me, who could say, that we would really like to help you with that.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Any reasons to stay anonymous? Hey, we don't/can't harm you in any way :) Instead, i think that it would be not only me, who could say, that we would really like to help you with that.
Well, my name is Gerard Navarro. Really is needed have real name and not an alias? :) -- View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3305535.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Now not :) This is a nice pseudo. I like also destinationVoid (frank herbert) Stef
Any reasons to stay anonymous? Hey, we don't/can't harm you in any way :) Instead, i think that it would be not only me, who could say, that we would really like to help you with that.
Well, my name is Gerard Navarro. Really is needed have real name and not an alias? :)
-- View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3305535.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
2009/7/22 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Now not :) This is a nice pseudo. I like also destinationVoid (frank herbert)
Yeah, if you remember, i was using own alias before (Sig) but then someone asked me to uncover my true identity :)
Stef
Any reasons to stay anonymous? Hey, we don't/can't harm you in any way :) Instead, i think that it would be not only me, who could say, that we would really like to help you with that.
Well, my name is Gerard Navarro. Really is needed have real name and not an alias? :)
-- View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3305535.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
-- Best regards, Igor Stasenko AKA sig.
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
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
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.
Yeah, then zip the text file... much more compact! Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, July 21, 2009 5:28 PM Subject: Re: [Pharo-project] Persist a morph in a message.
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
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
Torsten, Are you wanting to resolve your storage format right now, or just improve the I/O? And, when the generalization/abstraction comes about, it seem that fonts should draw on local default setting and be adjusted "larger" and "smaller" somehow. I have two computers on my desktop right here that have wildly different screen resolutions. -cam On Jul 21, 2009, at 12:59 PM, Cameron Sanders wrote:
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| myMorph | myMorph := MyMorph new. myMorph layout: blablahblah.. myMorph label: blabla...
^ myMorph
Perhaps that is the more hard way for me, but perhaps is the more correct too :| is readable, and easy of modify externally to designer. Yesterday i probe the mse serialize, but generate a text bigger, and thrown a error in somes complex morphs :( Regards -- View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3312119.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
| myMorph |
myMorph := MyMorph new. myMorph layout: blablahblah.. myMorph label: blabla...
^ myMorph
Perhaps that is the more hard way for me, but perhaps is the more correct too :| is readable, and easy of modify externally to designer.
Yesterday i probe the mse serialize, but generate a text bigger, and thrown a error in somes complex morphs :(
could you report them because lukas was using that to save pier object. Now lukas is on vacation. Stef
could you report them because lukas was using that to save pier object.
Now lukas is on vacation.
Stef
Im very much newbie. Is correct report the bug in http://code.google.com/p/pharo/issues/list ?? Regards -- View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3312507.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
2009/7/23 nullPointer <epicfan@gmail.com>
could you report them because lukas was using that to save pier object.
Now lukas is on vacation.
Stef
Im very much newbie. Is correct report the bug in http://code.google.com/p/pharo/issues/list ??
yes it is :) You can read that here: http://www.pharo-project.org
Regards
------------------------------ View this message in context: Re: [Pharo-project] Persist a morph in a message.<http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3312507.html>
Sent from the Pharo Smalltalk mailing list archive<http://n2.nabble.com/Pharo-Smalltalk-f2305563.html>at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Perhaps you can use another serializer. Here a some: http://www.seaside.st/documentation/persistence
I did try sixx, but was failed for big morphs.The xml text resultant was too great.
Your project seems very interesting, tough.
Thanks, I am putting much effort to it :)) -- View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3295446.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Why don't you a kind of literalArray syntax like in VW. Declarative syntax for saving description are the way to go. I would not serialize the composite. You could use mse for example: there are loader and saver for mse in the Fame package I guess. Stef
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.
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
My apologies, I got confused about the source of this thread in my last email. nullPoint, nice start! (So that question in my last email was directed at you.) -Cam On Jul 20, 2009, at 6:15 PM, nullPointer 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.
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
participants (6)
-
Cameron Sanders -
Gary Chambers -
Igor Stasenko -
Mariano Martinez Peck -
nullPointer -
Stéphane Ducasse