[squeak-dev] Cuis updated to #0250

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Cuis updated to #0250

Juan Vuletich-4
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis updated to #0250

Igor Stasenko
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.
>
A most important thing (as to me), is the possibility to use different
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.

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Text Editors (was: Re: Cuis updated to #0250)

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis updated to #0250

K. K. Subramaniam
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis updated to #0250

Juan Vuletich-4
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


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Text Editors

Juan Vuletich-4
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


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Text Editors

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis updated to #0250

K. K. Subramaniam
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


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Text Editors

Juan Vuletich-4
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


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis updated to #0250

Juan Vuletich-4
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis updated to #0250

K. K. Subramaniam
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis updated to #0250

Juan Vuletich-4
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

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Text Editors

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Text Editors

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Text Editors

Juan Vuletich-4
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


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Text Editors

Juan Vuletich-4
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Text Editors

Randal L. Schwartz
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Text Editors

Bert Freudenberg

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 -



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Text Editors

Randal L. Schwartz
>>>>> "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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Text Editors

Bert Freudenberg

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 -



123