[FIX] TextMorphSelectionFix-rr ([sm][cd] new version)
stéphane ducasse
ducasse at iam.unibe.ch
Mon Aug 30 07:53:07 UTC 2004
Hi guys
this is again the proof that we need a Guide taking care of Etoy,
Multimedia aspects :)
Stef
On 30 août 04, at 09:07, 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>
More information about the Squeak-dev
mailing list
|