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>