Igor Stasenko wrote:
2009/8/2 Andreas Raab andreas.raab@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@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