I have created two methods for reconstructing those images:

PaintBoxMorph new colorMemory image writePNGfileNamed:
'pb_colorMemory.png'.
PaintBoxMorph class compile: 'colorMemoryImage
    ^ColorMemoryImage ifNil: [ColorMemoryImage := Form fromBinaryStream:
(Base64MimeConverter mimeDecodeToBytes:
        ' , ((FileStream fileNamed: 'pb_colorMemory.png')
        binary;
        contentsOfEntireFile) asString base64Encoded storeString , '
readStream)]' classified: 'resources'.

(PaintBoxMorph new instVarNamed: 'colorMemoryThin') image
writePNGfileNamed: 'pb_colorMemoryThin.png'.
PaintBoxMorph class compile: 'colorMemoryThinImage
    ^ColorMemoryThinImage ifNil: [ColorMemoryThinImage := Form
fromBinaryStream: (Base64MimeConverter mimeDecodeToBytes:
        ' , ((FileStream fileNamed: 'pb_colorMemoryThin.png')
        binary;
        contentsOfEntireFile) asString base64Encoded storeString , '
readStream)]' classified: 'resources'.

But I now see that those images are exactly like ColorChart class var, plus
a border (made with some blue gradient).
ColorChart is constructed, so the right way to initialize would be to
reconstruct rather than storing resulting bits.
But I also see that there are two ways to create this ColorChart, one in
class method #initializeColorChart, which creates a rather large one, the
other in instance method #fixUpColorPicker which is more inline with
current Prototype.
It's good to have a plethora of options, alas, if only a single one would
work...
If we unload MorphicExtras, then reload it, I doubt we can open a
PaintBoxMorph, because none of the init3, init4, etc.. does work from trunk.
BTW, does unloading MorphicExtras work for anyone? For me it results in an
emergency evaluator... So I could not even try this.

I regret putting my nose in this area, because I'm wasting too much time on
something not in my radar until now,
Sometimes, it makes me think Pharo has taken the most reasonnable path :(.

I agree that it's not necessary/desirable to have a programmatic way to
reconstruct everything, I would not like to program Mona Lisa, but then, if
we really want to use this style in trunk, we should better stop using
wrong tools like MC or try to engineer the image into programmed components.


2013/12/8 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>

> PaintBoxMorph new colorMemory image writePNGfileNamed:
> 'pb_colorMemory.png'.
> (Form fromBinaryStream: (Base64MimeConverter mimeDecodeToBytes:
>     ((FileStream fileNamed: 'pb_colorMemory.png')
>         binary;
>         contentsOfEntireFile) asString base64Encoded readStream)) asMorph
> openInWorld
>
>
>
> 2013/12/8 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
>
>> And a drawback of storing the bytes in a literal is that it doubles the
>> space required...
>> But then we don't need to clone a prototype (veryDeepCopy !!!)
>> If we're really chasing kbytes, then we should ban the prototype, so this
>> can't be an argument.
>>
>>
>> 2013/12/8 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
>>
>>> A few things:
>>> 1) PaintBoxMorph new is cloning a Prototype much like the self way.
>>> 2) above code is memorizing how the prototype was once initialized.
>>> 2.a) it will never be invoked again, unless we recreate a whole image
>>> 2.b) it does so partially... It does tell which file, but not from which
>>> server.
>>> The information of well known update server is no more in the image.
>>> You could find ftp.squeak.org recently in Utilities before I removed
>>> the class var...
>>> ... but ftp.squeak.org doesn't seem to know about colorPalClosed.obj.
>>> 3) I don't see an updateStream dependency in Installer core, only a
>>> dependency on its successor MCMcmUpdater
>>>
>>> 2.a) makes me think we don't need something complex.
>>> 2.b) makes me think it's time to replace/update the initialize mechanism
>>>
>>> I looked at the cached images, it's about 35kbytes, 16kBytes zipped.
>>> A possible alternative is to directly store those bytes in some literal
>>> (string -> uudecode -> unzip -> bits).
>>>
>>>
>>> 2013/12/8 Chris Muller <asqueaker at gmail.com>
>>>
>>>> On Sun, Dec 8, 2013 at 2:48 PM, Nicolas Cellier
>>>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>> > Well, above code depends on some bytes left on some file on the
>>>> internet,
>>>>
>>>> Not necessarily.  See Installer class>>#airplaneMode.
>>>>
>>>> Besides, even if it did, it's 2013 so developers are accustomed to
>>>> working with remote code repositories.
>>>>
>>>> > plus a bunch of methods to retrieve/decode/install those bytes as an
>>>> image.
>>>>
>>>> Which is a requirement of #core.  See comment for Installer>>#core.
>>>>
>>>> > We could as well imagine a shorter path...
>>>>
>>>> Like what?
>>>>
>>>>
>>>> > 2013/12/8 Chris Muller <asqueaker at gmail.com>
>>>> >>
>>>> >> MorphicExtras is "extras" so we can expect it to depend on myriad
>>>> >> other packages.  I'm surprised you and Frank aren't harping on such a
>>>> >> "catch-all" package.
>>>> >>
>>>> >> I thought to test the waters of making it a dynamic-dependency.
>>>> >>
>>>> >> On Sat, Dec 7, 2013 at 8:27 AM, Nicolas Cellier
>>>> >> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>> >> > On one hand, I find those bytes very useful if ever we'd like to
>>>> >> > recreate an
>>>> >> > image.
>>>> >> > But on the other hand, it creates a dependency.
>>>> >> > This makes a nice packaging problem, how to handle it?
>>>> >> > One possibility would be to encode image data in some kind of
>>>> literal
>>>> >> > (packed string, byte array, ...), and store & decode this literal
>>>> in
>>>> >> > some
>>>> >> > class initialization method...
>>>> >> > Anyway, the name and location of file does not bring much value now
>>>> >> > (just
>>>> >> > save a few bytes by avoiding duplication of image in a literal).
>>>> >> >
>>>> >> >
>>>> >> > 2013/12/7 <commits at source.squeak.org>
>>>> >> >
>>>> >> >> Nicolas Cellier uploaded a new version of MorphicExtras to
>>>> project The
>>>> >> >> Trunk:
>>>> >> >> http://source.squeak.org/trunk/MorphicExtras-nice.130.mcz
>>>> >> >>
>>>> >> >> ==================== Summary ====================
>>>> >> >>
>>>> >> >> Name: MorphicExtras-nice.130
>>>> >> >> Author: nice
>>>> >> >> Time: 7 December 2013, 3:18:35 pm
>>>> >> >> UUID: f1cfb1fa-c101-4329-b528-963fb90eef45
>>>> >> >> Ancestors: MorphicExtras-fbs.129
>>>> >> >>
>>>> >> >> Some initialization performed once in last century is depending on
>>>> >> >> UpdateStream.
>>>> >> >>
>>>> >> >> =============== Diff against MorphicExtras-fbs.129 ===============
>>>> >> >>
>>>> >> >> Item was changed:
>>>> >> >>   ----- Method: PaintBoxMorph>>loadColorChooser (in category
>>>> >> >> 'initialization') -----
>>>> >> >>   loadColorChooser
>>>> >> >>         "Load Forms for ColorMemoryMorph."
>>>> >> >>
>>>> >> >>         | doc closedForm openForm |
>>>> >> >> +       doc := UpdateStreamDownloader default
>>>> objectStrmFromUpdates:
>>>> >> >> 'colorPalClosed.obj'.
>>>> >> >> -       doc := Utilities objectStrmFromUpdates:
>>>> 'colorPalClosed.obj'.
>>>> >> >>         closedForm := doc fileInObjectAndCode mapColor: Color
>>>> >> >> transparent
>>>> >> >> to: Color black.
>>>> >> >> +       doc := UpdateStreamDownloader default
>>>> objectStrmFromUpdates:
>>>> >> >> 'colorPalOpen.obj'.
>>>> >> >> -       doc := Utilities objectStrmFromUpdates:
>>>> 'colorPalOpen.obj'.
>>>> >> >>         openForm := doc fileInObjectAndCode mapColor: Color
>>>> transparent
>>>> >> >> to: Color black.
>>>> >> >>
>>>> >> >>         colorMemoryThin image: closedForm.
>>>> >> >>         colorMemoryThin position: self position + (0 at 140).
>>>> >> >>
>>>> >> >>         colorMemory delete.     "delete old one"
>>>> >> >>         colorMemory := PaintBoxColorPicker new image: openForm.
>>>> >> >>   !
>>>> >> >>
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131209/51c0b310/attachment.htm