from preamble:
"Change Set: FocusFixes-rr Date: 23 March 2004 Author: Romain Robbes
V2 : provides more visual feedback by changing the selection color upon focus change, as suggested by Hernán Tylim.
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.
Also included are the changes in PluggableTextMorph and StrikeFont, to allow menus to be invoked modally, and thus having keyboard control if the preference is set"!
Hi Romain,
If I may, a couple of more suggestions.
- make the colors be clearly distinct between each other. In my monitor (a very old and used one, I admit it) they look pretty much the same.
- If the selection has a wide of zero, make it transparent if it has no focus.
Take the following and please evaluate it on a workspace:
SystemWindow new setWindowColor: Color lightGray; addMorph: (PluggableTextMorph on: nil text: nil accept: nil) frame: (0@0 corner: 1@0.25); addMorph: (PluggableTextMorph on: nil text: nil accept: nil) frame: (0@0.25 corner: 1@0.5); addMorph: (PluggableTextMorph on: nil text: nil accept: nil) frame: (0@0.5 corner: 1@0.75); addMorph: (PluggableTextMorph on: nil text: nil accept: nil) frame: (0@0.75 corner: 1@1); openInHand.
What you see here is a window with 4 text fields. The all 4 are showing a text cursor and for me it's not clearly which one has focus.
Side note: In my opinion the root of the problem here is that 'text selection' and 'text cursor' are a same concept on Squeak while they should be two separate ones.
Regards, Hernan
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]En nombre de rrobbes@info.unicaen.fr Enviado el: Lunes, 22 de Marzo de 2004 09:54 Para: squeak-dev@lists.squeakfoundation.org Asunto: [FIX] TextMorphSelectionFix-rr ([sm][cd] new version)
from preamble:
"Change Set: FocusFixes-rr Date: 23 March 2004 Author: Romain Robbes
V2 : provides more visual feedback by changing the selection color upon focus change, as suggested by Hernan Tylim.
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.
Also included are the changes in PluggableTextMorph and StrikeFont, to allow menus to be invoked modally, and thus having keyboard control if the preference is set"!
This change looks like a good idea to me. Two problems I noticed with this, though:
1. The lost-focus selection color did not look different enough to me... at least with the default bright green color, the lost-focus color was still almost as bright a green. I fixed this by changing the line in NewParagraph>>selectionColor to:
self focused ifFalse: [color := color alphaMixed: 0.2 with: Color veryVeryLightGray].
2. The vertical-bar cursor (when there is no selection) does not dissappear or change color when a window loses focus. I'd say it should probably dissappear (this is what Windows does and probably the Mac as well), although changing color to the lost-focus selectionColor above might be an option. Hmm, no, it should really just dissappear. :-)
If we can address #2, I'd like to approve this one.
- Doug
rrobbes@info.unicaen.fr wrote:
from preamble:
"Change Set: FocusFixes-rr Date: 23 March 2004 Author: Romain Robbes
V2 : provides more visual feedback by changing the selection color upon focus change, as suggested by Hernán Tylim.
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.
Also included are the changes in PluggableTextMorph and StrikeFont, to allow menus to be invoked modally, and thus having keyboard control if the preference is set"!
Doug Way a écrit:
This change looks like a good idea to me. Two problems I noticed with this, though:
- The lost-focus selection color did not look different enough to me...
at least with the default bright green color, the lost-focus color was still almost as bright a green. I fixed this by changing the line in NewParagraph>>selectionColor to:
self focused ifFalse: [color := color alphaMixed: 0.2 with: Color veryVeryLightGray].
Well I fiddled quite a bit to find a good color, and this looked good on my screen ... I'll try this one too.
- The vertical-bar cursor (when there is no selection) does not
dissappear or change color when a window loses focus. I'd say it should probably dissappear (this is what Windows does and probably the Mac as well), although changing color to the lost-focus selectionColor above might be an option. Hmm, no, it should really just dissappear. :-)
Haven't looked at that yet ... I think the option might be easier, but I'll try to make it disappear ...
If we can address #2, I'd like to approve this one.
- Doug
rrobbes@info.unicaen.fr wrote:
from preamble:
"Change Set: FocusFixes-rr Date: 23 March 2004 Author: Romain Robbes
V2 : provides more visual feedback by changing the selection color upon focus change, as suggested by Hernán Tylim.
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.
Also included are the changes in PluggableTextMorph and StrikeFont, to allow menus to be invoked modally, and thus having keyboard control if the preference is set"!
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,
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
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@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>
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>
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>
squeak-dev@lists.squeakfoundation.org
-
Doug Way -
Hernan Tylim -
Ned Konz -
Romain Robbes -
rrobbes
-
rrobbes＠info.unicaen.fr
-
Scott Wallace -
stéphane ducasse