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@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>