I agree with Ned that having multiple concurrent selections in loose 
TextMorphs is a real problem.

That inactive *windows* which bear text, such as Browsers and 
Workspaces, should retain their text selections, showing them with 
subdued highlighting feedback, is nowadays quite standard practice in 
text-handling applications (at least on the Mac,) so I think the 
intentions in 5849TextMorphSelectionFix-rr were good for those 
text-in-windows situations.

What's not good -- not even acceptable -- is for multiple *loose* 
TextMorphs to retain and show their selections.  Our Squeakland 
users, mostly, never see a SystemWindow in Squeak -- instead they use 
plain TextMorphs, which they place either directly onto the desktop 
or onto a playfield or book page.  In all these cases, showing 
multiple selections is both annoying and, actually, completely 
pointless, because to edit an inactive loose TextMorph, you need to 
click on it to give it keyboard focus, and that click will inevitably 
put down an insertion point, thus clobbering the remembered selection 
anyway.

(Most squeak-dev subscribers probably only use text in windows [as 
opposed to loose TextMorphs] which may explain why no one has 
complained about this until now.)

I offer, attached, a possible compromise solution, which moves 
Romain's changes from TextMorph down to TextMorphForEditView, and 
restores the former highlighting behavior for loose TextMorphs.

This does mean that the visible selection feedback on a loose 
TextMorph disappears when you pop up a menu, like it used to.  But 
note Ned's comment below: "I'm sure we can fix the menus some other 
way."


Cheers,

   -- Scott

At 10:13 PM -0700 8/29/04, Ned Konz wrote:
>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
-------------- next part --------------
Skipped content of type multipart/appledouble