[squeak-dev] Cuis updated to #0250
Locked
123
123
[squeak-dev] Cuis updated to #0250
 
|
A new release of Cuis is available at
http://www.jvuletich.org/Cuis/Index.html . It includes some bugfixes and more cleanup. Biggest news is a lot of cleanup in the Text system. Gone are the ugly TextConstants pool and the old Paragraph class. TextStyle lost over half its instance variables and over 80% of its methods. I also added a TextEditor to the World menu that is not a Smalltalk Workspace and may be useful especially for end users. As usual, all the updates starting at #0001 are available separately, and described in http://www.jvuletich.org/Cuis/CategoriesAndChangeSets.txt . This could be useful for users of other Squeak images wanting some of the bug fixes and enhancements included in Cuis. Comments welcome. Cheers, Juan Vuletich |
Re: [squeak-dev] Cuis updated to #0250
|
|
2009/8/1 Juan Vuletich <[hidden email]>:
> A new release of Cuis is available at > http://www.jvuletich.org/Cuis/Index.html . It includes some bugfixes and > more cleanup. > > Biggest news is a lot of cleanup in the Text system. Gone are the ugly > TextConstants pool and the old Paragraph class. TextStyle lost over half its > instance variables and over 80% of its methods. I also added a TextEditor to > the World menu that is not a Smalltalk Workspace and may be useful > especially for end users. > > As usual, all the updates starting at #0001 are available separately, and > described in http://www.jvuletich.org/Cuis/CategoriesAndChangeSets.txt . > This could be useful for users of other Squeak images wanting some of the > bug fixes and enhancements included in Cuis. > > Comments welcome. > text editor class instead of 'buffing' single one, as it was before. We are all witness where buffing leads. > Cheers, > Juan Vuletich > > -- Best regards, Igor Stasenko AKA sig. |
[squeak-dev] Text Editors (was: Re: Cuis updated to #0250)
|
|
In reply to this post by Juan Vuletich-4
Juan Vuletich wrote:
> Biggest news is a lot of cleanup in the Text system. Gone are the ugly > TextConstants pool and the old Paragraph class. TextStyle lost over half > its instance variables and over 80% of its methods. I also added a > TextEditor to the World menu that is not a Smalltalk Workspace and may > be useful especially for end users. I very much like what you've done with the editors. Is it correct that TextEditor is effectively protocol compatible with the old TextMorphEditor? If so, what do you think about bringing this into Squeak and phase out TextMorphEditor? Would this be doable or do you foresee any problems due to other changes that you might have done? From what I can see it looks as if this should be possible while preserving all the Unicode and m17n-goodness that I don't want to give up for Squeak. But boy, I would like to finally cut the Gordian knot called ParagraphEditor that ties Morphic and MVC together at the hip ;-) Cheers, - Andreas |
Re: [squeak-dev] Cuis updated to #0250
|
|
In reply to this post by Juan Vuletich-4
On Saturday 01 Aug 2009 3:35:02 am Juan Vuletich wrote:
> I also added a > TextEditor to the World menu that is not a Smalltalk Workspace and may > be useful especially for end users. I didn't see any Text editor in the World menu or 'open..' menu. I was able to create a new TextMorph and edit it. The selection behavior is unusual. If I select some text and then click outside the morph, the selection hint goes gray instead of vanishing. If I then click back in the selection, the green color hint returns and text stays selected instead of changing to a | cursor. Is this working as designed? Subbu |
Re: [squeak-dev] Cuis updated to #0250
|
|
K. K. Subramaniam wrote:
> On Saturday 01 Aug 2009 3:35:02 am Juan Vuletich wrote: > >> I also added a >> TextEditor to the World menu that is not a Smalltalk Workspace and may >> be useful especially for end users. >> > I didn't see any Text editor in the World menu or 'open..' menu. I was able to > create a new TextMorph and edit it. World / open / text editor. Or alternatively 'Stuff'edit. > The selection behavior is unusual. If I > select some text and then click outside the morph, the selection hint goes > gray instead of vanishing. If I then click back in the selection, the green > color hint returns and text stays selected instead of changing to a | cursor. > > Is this working as designed? > Yes. But that is due to another change I did. If you hold the button down for a little, you get the right-click menu. This is very useful for PDA and other pen based systems, and it actually mimics the behavior of such systems (at least that of my old WinCE pda). Cheers, Juan Vuletich > Subbu |
Re: [squeak-dev] Text Editors
|
|
In reply to this post by Andreas.Raab
Andreas Raab wrote:
> Juan Vuletich wrote: >> Biggest news is a lot of cleanup in the Text system. Gone are the >> ugly TextConstants pool and the old Paragraph class. TextStyle lost >> over half its instance variables and over 80% of its methods. I also >> added a TextEditor to the World menu that is not a Smalltalk >> Workspace and may be useful especially for end users. > > I very much like what you've done with the editors. Is it correct that > TextEditor is effectively protocol compatible with the old > TextMorphEditor? If so, what do you think about bringing this into > Squeak and phase out TextMorphEditor? Would this be doable or do you > foresee any problems due to other changes that you might have done? > From what I can see it looks as if this should be possible while > preserving all the Unicode and m17n-goodness that I don't want to give > up for Squeak. But boy, I would like to finally cut the Gordian knot > called ParagraphEditor that ties Morphic and MVC together at the hip ;-) :) I think it can be done. I did not change the protocol. At most I might have removed some methods that are unused on Cuis. I'll try to do it. I'll file my Editor hierarchy in Squeak, add any missing methods (but not those of Controller!). Biggest problem is that I'll have to suffer the pain of the bloat in my mind, and the default font in my eyes :) If only some brave soul understood that Unicode and m17n should be an optional package and made it be so... Cheers, Juan Vuletich > Cheers, > - Andreas |
|
|
Juan Vuletich wrote:
> I think it can be done. I did not change the protocol. At most I might > have removed some methods that are unused on Cuis. I'll try to do it. > I'll file my Editor hierarchy in Squeak, add any missing methods (but > not those of Controller!). Biggest problem is that I'll have to suffer > the pain of the bloat in my mind, and the default font in my eyes :) Well, help us! You probably have a standing invitation to become core-dev in your inbox and if not I can get you one ;-) Cheers, - Andreas |
Re: [squeak-dev] Cuis updated to #0250
|
|
In reply to this post by Juan Vuletich-4
On Saturday 01 Aug 2009 6:07:38 pm Juan Vuletich wrote:
> K. K. Subramaniam wrote: > > I didn't see any Text editor in the World menu or 'open..' menu. I was > > able to create a new TextMorph and edit it. > > World / open / text editor. Or alternatively 'Stuff'edit. Mea Culpa. I was using an older version :-(. #edit is a neat idea. It can be consistently applied to any unlocked morph (e.g. LineMorph, PolygonMorph, SketchMorph etc.). Shift-click and edit Halo handle can be tied to this message. The message can be ignored by locked morphs (e.g. labels). > Yes. But that is due to another change I did. If you hold the button > down for a little, you get the right-click menu. This is very useful for > PDA and other pen based systems, and it actually mimics the behavior of > such systems (at least that of my old WinCE pda). Nice feature. But a hold (tap and wait) is different from a click. Shouldn't the event be handled in TextEditor>>mouseUp: where the waiting time can be checked? BTW, In PluggableTextMorph>>keystroke: there is a typo "keywtroke" in comments. Subbu |
Re: [squeak-dev] Re: Text Editors
|
|
In reply to this post by Andreas.Raab
Andreas Raab wrote:
> Juan Vuletich wrote: >> I think it can be done. I did not change the protocol. At most I >> might have removed some methods that are unused on Cuis. I'll try to >> do it. I'll file my Editor hierarchy in Squeak, add any missing >> methods (but not those of Controller!). Biggest problem is that I'll >> have to suffer the pain of the bloat in my mind, and the default font >> in my eyes :) 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. Besides, too much methods would be missing. Then I tried the other way. I cloned the existing TextMorphEditor hierarchy, made the superclass of my new ParagraphEditor2 to be object, and started cleaning Undeclared variables, etc. I believe this is the way to do it, because if done carefully, no methods would be missing and no behavior should be broken inadvertently. It would take me between 30 and 40 hours to finish it. I'm sorry, but I can't spend that much time on this. > Well, help us! You probably have a standing invitation to become > core-dev in your inbox and if not I can get you one ;-) 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? Cheers, Juan Vuletich > Cheers, > - Andreas |
Re: [squeak-dev] Cuis updated to #0250
|
|
In reply to this post by K. K. Subramaniam
K. K. Subramaniam wrote:
> On Saturday 01 Aug 2009 6:07:38 pm Juan Vuletich wrote: > >> K. K. Subramaniam wrote: >> >>> I didn't see any Text editor in the World menu or 'open..' menu. I was >>> able to create a new TextMorph and edit it. >>> >> World / open / text editor. Or alternatively 'Stuff'edit. >> > Mea Culpa. I was using an older version :-(. > > #edit is a neat idea. It can be consistently applied to any unlocked morph > (e.g. LineMorph, PolygonMorph, SketchMorph etc.). Shift-click and edit Halo > handle can be tied to this message. The message can be ignored by locked > morphs (e.g. labels). > > >> Yes. But that is due to another change I did. If you hold the button >> down for a little, you get the right-click menu. This is very useful for >> PDA and other pen based systems, and it actually mimics the behavior of >> such systems (at least that of my old WinCE pda). >> > Nice feature. But a hold (tap and wait) is different from a click. Shouldn't > the event be handled in TextEditor>>mouseUp: where the waiting time can be > checked? > It could, I guess. What's the problem with how I did it (in ##waitForSimulatedYellow:event:)? > BTW, In PluggableTextMorph>>keystroke: there is a typo "keywtroke" in > comments. > > Subbu Cheers, Juan Vuletich |
Re: [squeak-dev] Cuis updated to #0250
|
|
On Sunday 02 Aug 2009 7:52:57 am Juan Vuletich wrote:
> > Nice feature. But a hold (tap and wait) is different from a click. > > Shouldn't the event be handled in TextEditor>>mouseUp: where the waiting > > time can be checked? > It could, I guess. What's the problem with how I did it (in > ##waitForSimulatedYellow:event:)? I couldn't reset the cursor position using a click on the selection (imagine the whole text is selected. How do I cancel it?). I couldn't reselect a subtext within selection using a drag. If the word "thisisalongword" is selected and you try dragging "long", the selection shortens to "thisisalong". I traced this annoyance to TextEditor>>mouseDown: (oldInterval includes: b stringIndex) ifTrue: [ ^self ]. If the gesture is detected at mouseUp time, then there is no ambiguity between quick click, long click and double-click. Press-to-popup menu violates principle of least astonishment. If the mouse is moved slightly during a slow click, the menu popups, an item gets picked and the popup disappears in flash leaving no time to see which item got picked. BTW, when you eliminated scroll bars for fully visible lists and texts, you also eliminated the context menu button at the top :-(. Subbu |
Re: [squeak-dev] Cuis updated to #0250
|
|
K. K. Subramaniam wrote:
> On Sunday 02 Aug 2009 7:52:57 am Juan Vuletich wrote: > >>> Nice feature. But a hold (tap and wait) is different from a click. >>> Shouldn't the event be handled in TextEditor>>mouseUp: where the waiting >>> time can be checked? >>> >> It could, I guess. What's the problem with how I did it (in >> ##waitForSimulatedYellow:event:)? >> > I couldn't reset the cursor position using a click on the selection (imagine > the whole text is selected. How do I cancel it?). I couldn't reselect a > subtext within selection using a drag. If the word "thisisalongword" is > selected and you try dragging "long", the selection shortens to "thisisalong". > I traced this annoyance to TextEditor>>mouseDown: > (oldInterval includes: b stringIndex) ifTrue: [ ^self ]. > That line of code has this comment above: "If click is inside the selection, do not modify it. This is so the 'tap and wait' gesture (used to bring pop-up menu on pen devices) does not affect selection, allowing to do copy / paste of selection with menu on pen devices." If you remove that line, then when opening the menu, to do, for example, 'copy', you always lose the selection first. > If the gesture is detected at mouseUp time, then there is no ambiguity between > quick click, long click and double-click. > The problem is that click and drag, to select, is done in #mouseMove:, i.e. before #mouseUp:. So the decision on wether to keep the selection unchanged (because a menu request could follow) and allow the user to modify the selection, needs to be done in #mouseDown: / #mouseMove: Play a bit with the code. If you come up with something that works better, I'd be really happy. > Press-to-popup menu violates principle of least astonishment. If the mouse is > moved slightly during a slow click, the menu popups, an item gets picked and > the popup disappears in flash leaving no time to see which item got picked. > I agree. But I don't know a better way to do it, and pen computers do it like that. The only solution I see is to add a preference to enable press-to-menu only if you want it. > BTW, when you eliminated scroll bars for fully visible lists and texts, you > also eliminated the context menu button at the top :-(. > That's what the press-to-menu gesture is for, right? They are not hard to add back. But I think it makes no sense to have a scrollbar that has nothing to scroll. > Subbu Cheers, Juan Vuletich |
|
|
In reply to this post by Juan Vuletich-4
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. Cheers, - Andreas |
Re: [squeak-dev] Re: Text Editors
|
|
2009/8/2 Andreas Raab <[hidden email]>:
> 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? > Cheers, > - Andreas > > -- Best regards, Igor Stasenko AKA sig. |
Re: [squeak-dev] Re: Text Editors
|
|
In reply to this post by Andreas.Raab
Andreas Raab wrote:
> 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. Great!!! My mistake here is that I want to know exactly what behavior I'm modifying. So I turned to the other approach, using clones of the existing classes. That faced me to the need to check perhaps 40 senders for each of about 100 methods that would be modified or removed. Checking 4000 methods is no fun! Good you tried the more reasonable way. > 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. You're right. I'll add a preference for that for Cuis, but as it is done outside TextEditor (in MouseClickState), for Squeak, the best is to just remove it. This is easy. In TextEditor>>mouseDown: remove the line: (oldInterval includes: b stringIndex) ifTrue: [ ^self ]. > * 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). I moved them to SmalltalkEditor subclass. I'd not add it to Squeak, as the "proper" refactoring (moving down lots of methods from TextEditor to SmalltalkEditor) is not yet done. So, just fold the 4 class methods from SmalltalkEditor into TextEditor. Or you can load them from TextMorphEditor. > Other than that I haven't found any problems whatsoever yet. Excellent! >> 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. Good idea, thanks! I'll try to build an updated package for Squeak using this. Cheers, Juan Vuletich > > Cheers, > - Andreas |
Re: [squeak-dev] Re: Text Editors
|
|
In reply to this post by Igor Stasenko
Igor Stasenko wrote:
> 2009/8/2 Andreas Raab <[hidden email]>: > >> 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 |
Re: [squeak-dev] Re: Text Editors
|
|
In reply to this post by Igor Stasenko
>>>>> "Igor" == Igor Stasenko <[hidden email]> writes:
Igor> someData Igor> "iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP Igor> bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f Igor> z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Igor> Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII= Igor> " How is this different from someData ^' .... ' other than requiring a lot more confusing magic? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
Re: [squeak-dev] Re: Text Editors
|
|
On 02.08.2009, at 21:36, Randal L. Schwartz wrote: >>>>>> "Igor" == Igor Stasenko <[hidden email]> writes: > > > Igor> someData > Igor> > "iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP > Igor> bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/ > P5/P5fD6f > Igor> z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw > +n8/n8/l8 > Igor> Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/ > P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII= > Igor> " > > How is this different from > > someData > ^' .... ' > > other than requiring a lot more confusing magic? Commment ∉ Literals - Bert - |
Re: [squeak-dev] Re: Text Editors
|
|
>>>>> "Bert" == Bert Freudenberg <[hidden email]> writes:
Bert> Commment ∉ Literals Yes, I understand that. To put the data into a comment means some magic has to happen to parse source text to get at the value. To put the data into a literal means I simply call the method to get the value. What's the downside of having it as a literal? I know the downside of having it as a comment: far more mechanism, and thus, more fragile code and maintenance. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
Re: [squeak-dev] Re: Text Editors
|
|
On 02.08.2009, at 21:59, Randal L. Schwartz wrote: >>>>>> "Bert" == Bert Freudenberg <[hidden email]> writes: > > Bert> Commment ∉ Literals > > Yes, I understand that. > > To put the data into a comment means some magic has to happen to parse > source text to get at the value. > > To put the data into a literal means I simply call the method to get > the value. > > What's the downside of having it as a literal? > > I know the downside of having it as a comment: far more mechanism, > and thus, > more fragile code and maintenance. Literals are actual objects in the image. - Bert - |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |