Igor Stasenko wrote:
> 2009/8/2 Andreas Raab <andreas.raab at gmx.de>:
>   
>> Juan Vuletich wrote:
>>     
>>> I guess I was being too optimistic. I honestly tried to do it. First I
>>> tried to file in the Editor classes from Cuis. Unfortunately, they are
>>> differences that make them incompatible, for example in NewParagraph.
>>>       
>> I did it slightly differently and had no problems:
>> * File out Editor, TextEditor, file those into Squeak.
>> * Make a subclass of TextMorph called TextEditorMorph
>> * Give it the editorClass TextEditor, open it, edit it
>> At this point I had one blow-up resulting from missing
>> NewParagraph>>replaceFrom:to:with:. I added it and everything seemed to
>> work.
>>
>> I then upped the ante a little and replaced TextMorph>>editorClass with
>> TextEditor. And guess what, it seems to be working quite well, except from a
>> few issues like:
>> * One cannot get rid of text selection by clicking inside the old selection.
>> I'm presuming that this is done for mobile devices but we should have a
>> preference for governing that.
>> * Programming short cuts do not work (browse senders, implementors etc). How
>> are shortcuts expected to work here? Should these be in a subclass? (some
>> advice would be welcome).
>>
>> Other than that I haven't found any problems whatsoever yet.
>>
>>     
>>> I know. Perhaps my anti aliased StrikeFonts could be included in Squeak. I
>>> don't know how to handle the creation of instances. Monticello can only
>>> handle code, right? No live instances or binary (bmp) files?
>>>       
>> We can work this out. In the worst case, initializer methods can carry code
>> as well, along the lines of:
>>
>> blankForm
>>  "Created using:
>>    (ByteArray streamContents:[:s|
>>        PNGReadWriter
>>            putForm: (Form extent: 100 at 100 depth: 32)
>>            onStream: s]) asString base64Encoded.
>>  "
>>  ^Form fromBinaryStream: (
>> 'iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP
>> bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f
>> z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8
>> Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII='
>>   ) base64Decoded asByteArray readStream.
>>
>> If we stick this into a temporary class that gets deleted in a later update
>> then the overhead is temporary.
>>
>>     
>
> Btw, about such overhead.. Recently i'm also added a data blob in a method.
> And i thought, that it would be cool to not persist the data as a
> code, but instead
> put it into the comment.
> So, a generic method , carrying a data blob could be just:
>
> someData
> "iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP
> bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f
> z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8
> Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII=
> "
>
> in this way given blob is not part of an image, it is a part of source files.
> And, by having a method source, it is easy to read a data from it.
> How do you like the idea

Interesting! The instance creation code would have to go look for the 
data in the method comment. I guess it makes sense if the idea is _not_ 
to remove the data. This might make sense, as someone might remove some 
font sizes, or convert them to a lower bit depth, and it would be nice 
to be able to recreate them again. Let's see how much it adds to the 
changes file.

Cheers,
Juan Vuletich