Hi,
On Aug 30, 2004, at 9: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.)
Yes, that's what I mostly do for example. I also agree with what Stéphane just said about us needing a Guide for Etoy.
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 seems a good compromise to me. I'll review it on BFAV ASAP.
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."
The advantages of this solution is that it retains the selection of the textmorph, which is useful when one wants to use a menu item which needs a selection (such as the refactoring browsers's extract method), and uses typing to select the menu item.
Cheers, Romain
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>