Scott's analysis here sounds accurate.  Text-handling applications 
(such as Apple Mail) on Mac OS X do show multiple text selections in 
different windows, but the non-active selections are a dull/gray color. 
  I thought this was also true of Windows apps lately but I don't have a 
machine handy to test right now.

One nice side effect of the new behavior is that if you have a debugger 
up and you happen to move the mouse out of the debugger text pane, the 
current pc range selection is still shown. (it used to *really* annoy 
me that it disappeared and you'd have to move the mouse back in to see 
it, or hit "Where")  This means that we should be able to get rid of 
the "Where" button/menu item in the debugger now.

Moving the behavior from TextMorph down to TextMorphWithEditView sounds 
like a reasonable solution to me too.

Is it okay if you change this in Squeakland, but we make the change in 
3.8alpha and not 3.7 (which is going final now)?

- Doug


On Monday, August 30, 2004, at 03:07 AM, Scott Wallace wrote:

> 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
> <textSelectionFix-sw.2.cs.gz>