[FIX] TextMorphSelectionFix-rr ([sm][cd] new version)

Ned Konz ned at bike-nomad.com
Mon Aug 30 05:13:22 UTC 2004


On Monday 22 March 2004 4:54 am, rrobbes at info.unicaen.fr wrote:
> Makes the selected text in a TextMorph not
> disappear when the morph loses focus,
> by removing the call to releaseEditor in
> TextMorph>>keyboardFocusChange:  .
>
> This makes the TextMorphs' behavior more
> consistent with text panes in the host platforms,
> and makes Squeak a more consistent with itself,
> as this will allow all menus to behave according to
> the menuKeyboardControl preference, including
> the ones in a paragraph.

I realize that I'm a bit late commenting on this one, but I'm puzzled as to 
what exactly we're trying to fix.

After all, we don't need to change the UI itself just to get the 
menuKeyboardControl fixed. We just need to fix the forgetting of the focus 
while raising a menu, which can be done differently than it is in this change 
set.

I'm especially curious as to what 
> This makes the TextMorphs' behavior more
> consistent with text panes in the host platforms,
is supposed to mean.

In the "host platforms" I've looked at, there tends to be only one text 
selection per application.

And Squeak is one application, last time I checked.

It is not an operating system that is running multiple applications.

It is a single application with multiple "windows" of its own (even though 
those windows aren't real OS windows). Do you know of any multiple-window 
application that maintains multiple visible text selections?

The reason I'm asking is that we're trying to get a new Squeakland release 
together, and the behavior of the stand-alone TextMorph instances in the 
Objects tool has changed in an annoying fashion. There seems to be no way to 
get rid of the green selection highlight in them.

Is this *really* necessary? I'm sure we can fix the menus some other way.

Thanks,
-- 
Ned Konz
http://bike-nomad.com




More information about the Squeak-dev mailing list