[Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305 Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre, Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly. There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel. Bill ---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter David, You're a hero! Thanks for OB-Enhancements-dr.305 Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Bill, First of all, I did not authored this change. David did it. I guess this was a request emanated by a bunch of people. Well before OB- Enhancements-dr.305 was produced, I discussed with a few people in my group, and we all agree that not having the automatic focus on column was missing. No much work was necessary to make this change happen: OBPluggableListMorph>>mouseEnter: and OBPluggableTreeMorph>>mouseEnter: were simply removed. This is exactly what OB-Enhancements-dr.305 contains. Personally, the only reason why I am happy with the auto-focus, is by pressing Cmd-T to run tests. I find this quite convenient to simply accept a method, then move the moose to the column and press Cmd-T, without clicking. Although I do not see a scenario where auto-focus is a real problem, I do understand that David made an arbitrary decision without much consultation. Sorry about that. So, what do we do? Cheers, Alexandre On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote:
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi
First of all, I did not authored this change. David did it. I guess this was a request emanated by a bunch of people.
Yes.
Personally, the only reason why I am happy with the auto-focus, is by pressing Cmd-T to run tests. I find this quite convenient to simply accept a method, then move the moose to the column and press Cmd-T, without clicking.
yes. Another scenario from Stef: Having a method selected in the method list, going with the mouse button to the first column while having selected the hierarchy button and press key up or down to conveniently browse the same method in super- or subclasses.
Although I do not see a scenario where auto-focus is a real problem, I do understand that David made an arbitrary decision without much consultation. Sorry about that. So, what do we do?
Well, I did some "consultation" with Gary and Stef. But they left the decision to me, so I "decided" to be it like that for the moment to see how people react. I don't mind to, as Gary suggested, introduce yet another preference (there are already two related to this "auto-focus") saying whether one wants to ignore the mouseClickForKeyboardFocus preference in the browser's columns, although I personally think that such a preference is not needed as I can't imagine that this auto-focus for columns gets into the way too often (if at all). But if people want me to add such a pref, fine by me. I don't think we want to start a much ado about nothing discussion about this small change. ;) David
On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote:
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
David, Please read the post I just sent, the one proposing how to do all of this within usual rules of command routing. I agree that the behavior change is small (provided we are talking only about keyboard shortcuts), but your approach to it is not a small change: you are moving GUI code into the tools, which is bad practice. Please let Gary help you do this properly. In fact, I think we should have a slips-based inclusion criterion to keep the GUI code in one place. Having complete access to all of the code makes it easy to blur the model/view/controller/presenter boundaries. I _think_ that anything like this which sends certain messages (Gary can no doubt enumerate them) could and should be readily rewritten with commands in mind. It would help with keeping design clean as we go, so that if we ever choose to make use of native widgets, we'll have a prayer of succeeding w/o rewriting everything. It will also prevent hassles like we had early on with UI Enhancements (Polymorph's early form) with improvements breaking things that had not been converted. Bill ---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 9:17 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter Hi
First of all, I did not authored this change. David did it. I guess this was a request emanated by a bunch of people.
Yes.
Personally, the only reason why I am happy with the auto-focus, is by pressing Cmd-T to run tests. I find this quite convenient to simply accept a method, then move the moose to the column and press Cmd-T, without clicking.
yes. Another scenario from Stef: Having a method selected in the method list, going with the mouse button to the first column while having selected the hierarchy button and press key up or down to conveniently browse the same method in super- or subclasses.
Although I do not see a scenario where auto-focus is a real problem, I do understand that David made an arbitrary decision without much consultation. Sorry about that. So, what do we do?
Well, I did some "consultation" with Gary and Stef. But they left the decision to me, so I "decided" to be it like that for the moment to see how people react. I don't mind to, as Gary suggested, introduce yet another preference (there are already two related to this "auto-focus") saying whether one wants to ignore the mouseClickForKeyboardFocus preference in the browser's columns, although I personally think that such a preference is not needed as I can't imagine that this auto-focus for columns gets into the way too often (if at all). But if people want me to add such a pref, fine by me. I don't think we want to start a much ado about nothing discussion about this small change. ;) David
On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote:
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Bill,
but your approach to it is not a small change: you are moving GUI code into the tools, which is bad practice.
I do not really understand what you mean with "tools" here. I moved this code to the Morphic subclass we use to represent pluggable lists in OB (a subclass of PluggableListMorph), so this is the GUI code used in the tool and IMO the only place where I could possibly move this GUI code into, namely into other GUI code. ;)
Please let Gary help you do this properly.
Gary actually suggested me to do it like this. As I said, it's really the only way to realize this change so that it only affects the columns in OB, trust me. To make the extent of the change clear: What it does is to give the columns in OB-based browsers the focus whenever the mouse is over them. This only affects columns, nothing else, in the OB browser, and certainly also no other browsers, tools, whatsoever not based on OB. The question that remains is just whether people want a pref to enable/disable this changed behavior or not, I think. I don't have the impression that we need to discuss the implementation of this change. I will answer separately to your other mail. David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 9:17 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi
First of all, I did not authored this change. David did it. I guess this was a request emanated by a bunch of people.
Yes.
Personally, the only reason why I am happy with the auto-focus, is by pressing Cmd-T to run tests. I find this quite convenient to simply accept a method, then move the moose to the column and press Cmd-T, without clicking.
yes. Another scenario from Stef: Having a method selected in the method list, going with the mouse button to the first column while having selected the hierarchy button and press key up or down to conveniently browse the same method in super- or subclasses.
Although I do not see a scenario where auto-focus is a real problem, I do understand that David made an arbitrary decision without much consultation. Sorry about that. So, what do we do?
Well, I did some "consultation" with Gary and Stef. But they left the decision to me, so I "decided" to be it like that for the moment to see how people react. I don't mind to, as Gary suggested, introduce yet another preference (there are already two related to this "auto-focus") saying whether one wants to ignore the mouseClickForKeyboardFocus preference in the browser's columns, although I personally think that such a preference is not needed as I can't imagine that this auto-focus for columns gets into the way too often (if at all). But if people want me to add such a pref, fine by me.
I don't think we want to start a much ado about nothing discussion about this small change. ;)
David
On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote:
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
David, My gut tells me that it is risky to assume that the behavior must be in the list in order to affect only lists in OB. You do not need to alter focus to process a command, which is what you should be doing. Disturbing focus here is avoidable and incorrect. You make a very fine distinction between "in the tool" and in "GUI component" that exist only for the tool. There is a better way. Very few (complicated) things in GUI programming go by the shortest path. The window manager cannot do its job if it is not allowed to do it. I can elaborate with some examples, but I do not have time now. Commands are a decoupling that allow the GUI to control how things get processed while allowing individual tools to control what happens when commands are processed. It's not direct, but it correct. Bill ---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 10:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter Hi Bill,
but your approach to it is not a small change: you are moving GUI code into the tools, which is bad practice.
I do not really understand what you mean with "tools" here. I moved this code to the Morphic subclass we use to represent pluggable lists in OB (a subclass of PluggableListMorph), so this is the GUI code used in the tool and IMO the only place where I could possibly move this GUI code into, namely into other GUI code. ;)
Please let Gary help you do this properly.
Gary actually suggested me to do it like this. As I said, it's really the only way to realize this change so that it only affects the columns in OB, trust me. To make the extent of the change clear: What it does is to give the columns in OB-based browsers the focus whenever the mouse is over them. This only affects columns, nothing else, in the OB browser, and certainly also no other browsers, tools, whatsoever not based on OB. The question that remains is just whether people want a pref to enable/disable this changed behavior or not, I think. I don't have the impression that we need to discuss the implementation of this change. I will answer separately to your other mail. David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 9:17 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi
First of all, I did not authored this change. David did it. I guess this was a request emanated by a bunch of people.
Yes.
Personally, the only reason why I am happy with the auto-focus, is by pressing Cmd-T to run tests. I find this quite convenient to simply accept a method, then move the moose to the column and press Cmd-T, without clicking.
yes. Another scenario from Stef: Having a method selected in the method list, going with the mouse button to the first column while having selected the hierarchy button and press key up or down to conveniently browse the same method in super- or subclasses.
Although I do not see a scenario where auto-focus is a real problem, I do understand that David made an arbitrary decision without much consultation. Sorry about that. So, what do we do?
Well, I did some "consultation" with Gary and Stef. But they left the decision to me, so I "decided" to be it like that for the moment to see how people react. I don't mind to, as Gary suggested, introduce yet another preference (there are already two related to this "auto-focus") saying whether one wants to ignore the mouseClickForKeyboardFocus preference in the browser's columns, although I personally think that such a preference is not needed as I can't imagine that this auto-focus for columns gets into the way too often (if at all). But if people want me to add such a pref, fine by me.
I don't think we want to start a much ado about nothing discussion about this small change. ;)
David
On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote:
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Bill,
Commands are a decoupling that allow the GUI to control how things get processed while allowing individual tools to control what happens when commands are processed. It's not direct, but it correct.
I agree with you here. But see, this change is not really about commands. Alex gave you an example where this change is useful in the context of commands. But this was not the motivating example for me to do this change, I was not even aware that it could also be useful in Alex' scenario involving commands. The scenario I had in mind does not really employ commands at all, but basic keyboard actions like key up, key down (see my first mail in this thread). Maybe you can look at those as commands too, but the action they perform is certainly dependent on the view in which they are meant to happen. So there is more behind this than just "easing" the execution of commands. David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 10:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi Bill,
but your approach to it is not a small change: you are moving GUI code into the tools, which is bad practice.
I do not really understand what you mean with "tools" here. I moved this code to the Morphic subclass we use to represent pluggable lists in OB (a subclass of PluggableListMorph), so this is the GUI code used in the tool and IMO the only place where I could possibly move this GUI code into, namely into other GUI code. ;)
Please let Gary help you do this properly.
Gary actually suggested me to do it like this. As I said, it's really the only way to realize this change so that it only affects the columns in OB, trust me.
To make the extent of the change clear: What it does is to give the columns in OB-based browsers the focus whenever the mouse is over them. This only affects columns, nothing else, in the OB browser, and certainly also no other browsers, tools, whatsoever not based on OB.
The question that remains is just whether people want a pref to enable/disable this changed behavior or not, I think. I don't have the impression that we need to discuss the implementation of this change.
I will answer separately to your other mail.
David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 9:17 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi
First of all, I did not authored this change. David did it. I guess this was a request emanated by a bunch of people. Yes.
Personally, the only reason why I am happy with the auto-focus, is by pressing Cmd-T to run tests. I find this quite convenient to simply accept a method, then move the moose to the column and press Cmd-T, without clicking. yes. Another scenario from Stef: Having a method selected in the method list, going with the mouse button to the first column while having selected the hierarchy button and press key up or down to conveniently browse the same method in super- or subclasses.
Although I do not see a scenario where auto-focus is a real problem, I do understand that David made an arbitrary decision without much consultation. Sorry about that. So, what do we do? Well, I did some "consultation" with Gary and Stef. But they left the decision to me, so I "decided" to be it like that for the moment to see how people react. I don't mind to, as Gary suggested, introduce yet another preference (there are already two related to this "auto-focus") saying whether one wants to ignore the mouseClickForKeyboardFocus preference in the browser's columns, although I personally think that such a preference is not needed as I can't imagine that this auto-focus for columns gets into the way too often (if at all). But if people want me to add such a pref, fine by me.
I don't think we want to start a much ado about nothing discussion about this small change. ;)
David
On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote:
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
David, Keyboard up/down are events that can be translated into commands, and then "fired" up the hierarchy. It's been done this way for a long time. Very few custom components are in actually needed. Think of it as another incarnation (indeed literally in this case) of the old argument about composition vs. inheritance. Inheritance is wonderful, but in this case, it can/should be avoided. Plugging code into the correct places in a framework will avoid the need for the customized list. That is not to say that the OB lists are not needed - I do not know enough about them. However, a solid event/command framework would be hard pressed not to do the same thing, only better. Commands serve a role somewhat like exceptions. The problem/need is noticed in one area, the message is put in the correct channel and reviewed until somebody knows what to do with it. The overhead is (Gary - disagree if you feel the need) not so severe as with exceptions because it is a much more focused task. As an example, control-t for tests: you might also want to fire the same command from menus. Doing what I advocate makes that trivial. Dolphin does a great job of this kind of thing, right down to enabling/disabling commands vs. individual widgets. This assumes that OB itself (as a top level component) take a role in making all of this work. But that's a good thing once you adapt to it. In response to an earlier comment you made: there is always another way. Commands are the preferred one here - trust me. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger Sent: Friday, February 20, 2009 11:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter Hi Bill,
Commands are a decoupling that allow the GUI to control how things get processed while allowing individual tools to control what happens when commands are processed. It's not direct, but it correct.
I agree with you here. But see, this change is not really about commands. Alex gave you an example where this change is useful in the context of commands. But this was not the motivating example for me to do this change, I was not even aware that it could also be useful in Alex' scenario involving commands. The scenario I had in mind does not really employ commands at all, but basic keyboard actions like key up, key down (see my first mail in this thread). Maybe you can look at those as commands too, but the action they perform is certainly dependent on the view in which they are meant to happen. So there is more behind this than just "easing" the execution of commands. David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 10:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi Bill,
but your approach to it is not a small change: you are moving GUI code into the tools, which is bad practice.
I do not really understand what you mean with "tools" here. I moved this code to the Morphic subclass we use to represent pluggable lists in OB (a subclass of PluggableListMorph), so this is the GUI code used in the tool and IMO the only place where I could possibly move this GUI code into, namely into other GUI code. ;)
Please let Gary help you do this properly.
Gary actually suggested me to do it like this. As I said, it's really the only way to realize this change so that it only affects the columns in OB, trust me.
To make the extent of the change clear: What it does is to give the columns in OB-based browsers the focus whenever the mouse is over them. This only affects columns, nothing else, in the OB browser, and certainly also no other browsers, tools, whatsoever not based on OB.
The question that remains is just whether people want a pref to enable/disable this changed behavior or not, I think. I don't have the impression that we need to discuss the implementation of this change.
I will answer separately to your other mail.
David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 9:17 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi
First of all, I did not authored this change. David did it. I guess this was a request emanated by a bunch of people. Yes.
Personally, the only reason why I am happy with the auto-focus, is by pressing Cmd-T to run tests. I find this quite convenient to simply accept a method, then move the moose to the column and press Cmd-T, without clicking. yes. Another scenario from Stef: Having a method selected in the method list, going with the mouse button to the first column while having selected the hierarchy button and press key up or down to conveniently browse the same method in super- or subclasses.
Although I do not see a scenario where auto-focus is a real problem, I do understand that David made an arbitrary decision without much consultation. Sorry about that. So, what do we do? Well, I did some "consultation" with Gary and Stef. But they left the decision to me, so I "decided" to be it like that for the moment to see how people react. I don't mind to, as Gary suggested, introduce yet another preference (there are already two related to this "auto-focus") saying whether one wants to ignore the mouseClickForKeyboardFocus preference in the browser's columns, although I personally think that such a preference is not needed as I can't imagine that this auto-focus for columns gets into the way too often (if at all). But if people want me to add such a pref, fine by me.
I don't think we want to start a much ado about nothing discussion about this small change. ;)
David
On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote:
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
To be fair, there really isn't a well conceived command shortcut framework that works with the browsers/OB. Something to add to the list, perhaps a nice Summer of Code project. ParagraphEditor is the root of all evil to start with... Nevetheless, a simple preference for the new OB behaviour will settle the argument for all in the meantime. Let's move on. OB is getting there in terms of look and feel now. Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Friday, February 20, 2009 5:00 PM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter David, Keyboard up/down are events that can be translated into commands, and then "fired" up the hierarchy. It's been done this way for a long time. Very few custom components are in actually needed. Think of it as another incarnation (indeed literally in this case) of the old argument about composition vs. inheritance. Inheritance is wonderful, but in this case, it can/should be avoided. Plugging code into the correct places in a framework will avoid the need for the customized list. That is not to say that the OB lists are not needed - I do not know enough about them. However, a solid event/command framework would be hard pressed not to do the same thing, only better. Commands serve a role somewhat like exceptions. The problem/need is noticed in one area, the message is put in the correct channel and reviewed until somebody knows what to do with it. The overhead is (Gary - disagree if you feel the need) not so severe as with exceptions because it is a much more focused task. As an example, control-t for tests: you might also want to fire the same command from menus. Doing what I advocate makes that trivial. Dolphin does a great job of this kind of thing, right down to enabling/disabling commands vs. individual widgets. This assumes that OB itself (as a top level component) take a role in making all of this work. But that's a good thing once you adapt to it. In response to an earlier comment you made: there is always another way. Commands are the preferred one here - trust me. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger Sent: Friday, February 20, 2009 11:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter Hi Bill,
Commands are a decoupling that allow the GUI to control how things get processed while allowing individual tools to control what happens when commands are processed. It's not direct, but it correct.
I agree with you here. But see, this change is not really about commands. Alex gave you an example where this change is useful in the context of commands. But this was not the motivating example for me to do this change, I was not even aware that it could also be useful in Alex' scenario involving commands. The scenario I had in mind does not really employ commands at all, but basic keyboard actions like key up, key down (see my first mail in this thread). Maybe you can look at those as commands too, but the action they perform is certainly dependent on the view in which they are meant to happen. So there is more behind this than just "easing" the execution of commands. David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 10:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi Bill,
but your approach to it is not a small change: you are moving GUI code into the tools, which is bad practice.
I do not really understand what you mean with "tools" here. I moved this code to the Morphic subclass we use to represent pluggable lists in OB (a subclass of PluggableListMorph), so this is the GUI code used in the tool and IMO the only place where I could possibly move this GUI code into, namely into other GUI code. ;)
Please let Gary help you do this properly.
Gary actually suggested me to do it like this. As I said, it's really the only way to realize this change so that it only affects the columns in OB, trust me.
To make the extent of the change clear: What it does is to give the columns in OB-based browsers the focus whenever the mouse is over them. This only affects columns, nothing else, in the OB browser, and certainly also no other browsers, tools, whatsoever not based on OB.
The question that remains is just whether people want a pref to enable/disable this changed behavior or not, I think. I don't have the impression that we need to discuss the implementation of this change.
I will answer separately to your other mail.
David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 9:17 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi
First of all, I did not authored this change. David did it. I guess this was a request emanated by a bunch of people. Yes.
Personally, the only reason why I am happy with the auto-focus, is by pressing Cmd-T to run tests. I find this quite convenient to simply accept a method, then move the moose to the column and press Cmd-T, without clicking. yes. Another scenario from Stef: Having a method selected in the method list, going with the mouse button to the first column while having selected the hierarchy button and press key up or down to conveniently browse the same method in super- or subclasses.
Although I do not see a scenario where auto-focus is a real problem, I do understand that David made an arbitrary decision without much consultation. Sorry about that. So, what do we do? Well, I did some "consultation" with Gary and Stef. But they left the decision to me, so I "decided" to be it like that for the moment to see how people react. I don't mind to, as Gary suggested, introduce yet another preference (there are already two related to this "auto-focus") saying whether one wants to ignore the mouseClickForKeyboardFocus preference in the browser's columns, although I personally think that such a preference is not needed as I can't imagine that this auto-focus for columns gets into the way too often (if at all). But if people want me to add such a pref, fine by me.
I don't think we want to start a much ado about nothing discussion about this small change. ;)
David
On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote:
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Feb 20, 2009 at 6:26 PM, Gary Chambers <gazzaguru2@btinternet.com> wrote:
Something to add to the list, perhaps a nice Summer of Code project.
ParagraphEditor is the root of all evil to start with...
Safarà needs some work and is a valid replacement for ParagraphEditor. -- Damien Cassou http://damiencassou.seasidehosting.st
Gary, Sounds good on both fronts. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Friday, February 20, 2009 12:26 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter To be fair, there really isn't a well conceived command shortcut framework that works with the browsers/OB. Something to add to the list, perhaps a nice Summer of Code project. ParagraphEditor is the root of all evil to start with... Nevetheless, a simple preference for the new OB behaviour will settle the argument for all in the meantime. Let's move on. OB is getting there in terms of look and feel now. Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Friday, February 20, 2009 5:00 PM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter David, Keyboard up/down are events that can be translated into commands, and then "fired" up the hierarchy. It's been done this way for a long time. Very few custom components are in actually needed. Think of it as another incarnation (indeed literally in this case) of the old argument about composition vs. inheritance. Inheritance is wonderful, but in this case, it can/should be avoided. Plugging code into the correct places in a framework will avoid the need for the customized list. That is not to say that the OB lists are not needed - I do not know enough about them. However, a solid event/command framework would be hard pressed not to do the same thing, only better. Commands serve a role somewhat like exceptions. The problem/need is noticed in one area, the message is put in the correct channel and reviewed until somebody knows what to do with it. The overhead is (Gary - disagree if you feel the need) not so severe as with exceptions because it is a much more focused task. As an example, control-t for tests: you might also want to fire the same command from menus. Doing what I advocate makes that trivial. Dolphin does a great job of this kind of thing, right down to enabling/disabling commands vs. individual widgets. This assumes that OB itself (as a top level component) take a role in making all of this work. But that's a good thing once you adapt to it. In response to an earlier comment you made: there is always another way. Commands are the preferred one here - trust me. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger Sent: Friday, February 20, 2009 11:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter Hi Bill,
Commands are a decoupling that allow the GUI to control how things get processed while allowing individual tools to control what happens when commands are processed. It's not direct, but it correct.
I agree with you here. But see, this change is not really about commands. Alex gave you an example where this change is useful in the context of commands. But this was not the motivating example for me to do this change, I was not even aware that it could also be useful in Alex' scenario involving commands. The scenario I had in mind does not really employ commands at all, but basic keyboard actions like key up, key down (see my first mail in this thread). Maybe you can look at those as commands too, but the action they perform is certainly dependent on the view in which they are meant to happen. So there is more behind this than just "easing" the execution of commands. David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 10:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi Bill,
but your approach to it is not a small change: you are moving GUI code into the tools, which is bad practice.
I do not really understand what you mean with "tools" here. I moved this code to the Morphic subclass we use to represent pluggable lists in OB (a subclass of PluggableListMorph), so this is the GUI code used in the tool and IMO the only place where I could possibly move this GUI code into, namely into other GUI code. ;)
Please let Gary help you do this properly.
Gary actually suggested me to do it like this. As I said, it's really the only way to realize this change so that it only affects the columns in OB, trust me.
To make the extent of the change clear: What it does is to give the columns in OB-based browsers the focus whenever the mouse is over them. This only affects columns, nothing else, in the OB browser, and certainly also no other browsers, tools, whatsoever not based on OB.
The question that remains is just whether people want a pref to enable/disable this changed behavior or not, I think. I don't have the impression that we need to discuss the implementation of this change.
I will answer separately to your other mail.
David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 9:17 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi
First of all, I did not authored this change. David did it. I guess this was a request emanated by a bunch of people. Yes.
Personally, the only reason why I am happy with the auto-focus, is by pressing Cmd-T to run tests. I find this quite convenient to simply accept a method, then move the moose to the column and press Cmd-T, without clicking. yes. Another scenario from Stef: Having a method selected in the method list, going with the mouse button to the first column while having selected the hierarchy button and press key up or down to conveniently browse the same method in super- or subclasses.
Although I do not see a scenario where auto-focus is a real problem, I do understand that David made an arbitrary decision without much consultation. Sorry about that. So, what do we do? Well, I did some "consultation" with Gary and Stef. But they left the decision to me, so I "decided" to be it like that for the moment to see how people react. I don't mind to, as Gary suggested, introduce yet another preference (there are already two related to this "auto-focus") saying whether one wants to ignore the mouseClickForKeyboardFocus preference in the browser's columns, although I personally think that such a preference is not needed as I can't imagine that this auto-focus for columns gets into the way too often (if at all). But if people want me to add such a pref, fine by me.
I don't think we want to start a much ado about nothing discussion about this small change. ;)
David
On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote:
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Feb 20, 2009, at 6:26 PM, Gary Chambers wrote:
To be fair, there really isn't a well conceived command shortcut framework that works with the browsers/OB.
Something to add to the list, perhaps a nice Summer of Code project.
Yes if you mentor it I'm sure ESUG can finance one.
ParagraphEditor is the root of all evil to start with...
yes
Nevetheless, a simple preference for the new OB behaviour will settle the argument for all in the meantime. Let's move on. OB is getting there in terms of look and feel now.
Regards, Gary
----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Friday, February 20, 2009 5:00 PM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
David,
Keyboard up/down are events that can be translated into commands, and then "fired" up the hierarchy. It's been done this way for a long time. Very few custom components are in actually needed. Think of it as another incarnation (indeed literally in this case) of the old argument about composition vs. inheritance. Inheritance is wonderful, but in this case, it can/should be avoided. Plugging code into the correct places in a framework will avoid the need for the customized list. That is not to say that the OB lists are not needed - I do not know enough about them. However, a solid event/command framework would be hard pressed not to do the same thing, only better.
Commands serve a role somewhat like exceptions. The problem/need is noticed in one area, the message is put in the correct channel and reviewed until somebody knows what to do with it. The overhead is (Gary - disagree if you feel the need) not so severe as with exceptions because it is a much more focused task.
As an example, control-t for tests: you might also want to fire the same command from menus. Doing what I advocate makes that trivial. Dolphin does a great job of this kind of thing, right down to enabling/disabling commands vs. individual widgets.
This assumes that OB itself (as a top level component) take a role in making all of this work. But that's a good thing once you adapt to it.
In response to an earlier comment you made: there is always another way. Commands are the preferred one here - trust me.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger Sent: Friday, February 20, 2009 11:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi Bill,
Commands are a decoupling that allow the GUI to control how things get processed while allowing individual tools to control what happens when commands are processed. It's not direct, but it correct.
I agree with you here. But see, this change is not really about commands. Alex gave you an example where this change is useful in the context of commands. But this was not the motivating example for me to do this change, I was not even aware that it could also be useful in Alex' scenario involving commands. The scenario I had in mind does not really employ commands at all, but basic keyboard actions like key up, key down (see my first mail in this thread). Maybe you can look at those as commands too, but the action they perform is certainly dependent on the view in which they are meant to happen.
So there is more behind this than just "easing" the execution of commands.
David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 10:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi Bill,
but your approach to it is not a small change: you are moving GUI code into the tools, which is bad practice.
I do not really understand what you mean with "tools" here. I moved this code to the Morphic subclass we use to represent pluggable lists in OB (a subclass of PluggableListMorph), so this is the GUI code used in the tool and IMO the only place where I could possibly move this GUI code into, namely into other GUI code. ;)
Please let Gary help you do this properly.
Gary actually suggested me to do it like this. As I said, it's really the only way to realize this change so that it only affects the columns in OB, trust me.
To make the extent of the change clear: What it does is to give the columns in OB-based browsers the focus whenever the mouse is over them. This only affects columns, nothing else, in the OB browser, and certainly also no other browsers, tools, whatsoever not based on OB.
The question that remains is just whether people want a pref to enable/disable this changed behavior or not, I think. I don't have the impression that we need to discuss the implementation of this change.
I will answer separately to your other mail.
David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 9:17 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi
First of all, I did not authored this change. David did it. I guess this was a request emanated by a bunch of people. Yes.
Personally, the only reason why I am happy with the auto-focus, is by pressing Cmd-T to run tests. I find this quite convenient to simply accept a method, then move the moose to the column and press Cmd-T, without clicking. yes. Another scenario from Stef: Having a method selected in the method list, going with the mouse button to the first column while having selected the hierarchy button and press key up or down to conveniently browse the same method in super- or subclasses.
Although I do not see a scenario where auto-focus is a real problem, I do understand that David made an arbitrary decision without much consultation. Sorry about that. So, what do we do? Well, I did some "consultation" with Gary and Stef. But they left the decision to me, so I "decided" to be it like that for the moment to see how people react. I don't mind to, as Gary suggested, introduce yet another preference (there are already two related to this "auto-focus") saying whether one wants to ignore the mouseClickForKeyboardFocus preference in the browser's columns, although I personally think that such a preference is not needed as I can't imagine that this auto-focus for columns gets into the way too often (if at all). But if people want me to add such a pref, fine by me.
I don't think we want to start a much ado about nothing discussion about this small change. ;)
David
On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote:
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Concerning keyboard focus and mouse scroll. (sorry, if it was already noted in this discussion, i didn't read it fully). VM does not have a mouse wheel events. Instead, it generates ctrl-up / ctrl-down key combinations. I think that this hack is the root of all problems: - if focus doesn't following the mouse, you need additional hacks in image to treat ctrl-up / ctrl-down keys to generate scroll events for morph which is currently under the mouse, not the morph which is currently having an active keyboard input focus. -- Best regards, Igor Stasenko AKA sig.
Which is handled in Polymorph of course. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, February 21, 2009 3:59 AM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Concerning keyboard focus and mouse scroll. (sorry, if it was already noted in this discussion, i didn't read it fully).
VM does not have a mouse wheel events. Instead, it generates ctrl-up / ctrl-down key combinations. I think that this hack is the root of all problems: - if focus doesn't following the mouse, you need additional hacks in image to treat ctrl-up / ctrl-down keys to generate scroll events for morph which is currently under the mouse, not the morph which is currently having an active keyboard input focus.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Gary, Of course :) You guys are doing a great job! I just replied to Sig, emphasizing the Gnome/Windows split on scrolling based on cursor position while leaving the focus alone. Gnome has it right. However, I would give priority to consistent focus before worrying about sending the wheel input where it belongs. Sounds like we need to add wheel events to the VM; then it should be easy to handle both (control-up/down for older vms, and wheel events doing exactly what is desired by the user). Bill ---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers [gazzaguru2@btinternet.com] Sent: Saturday, February 21, 2009 8:02 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter Which is handled in Polymorph of course. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, February 21, 2009 3:59 AM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Concerning keyboard focus and mouse scroll. (sorry, if it was already noted in this discussion, i didn't read it fully).
VM does not have a mouse wheel events. Instead, it generates ctrl-up / ctrl-down key combinations. I think that this hack is the root of all problems: - if focus doesn't following the mouse, you need additional hacks in image to treat ctrl-up / ctrl-down keys to generate scroll events for morph which is currently under the mouse, not the morph which is currently having an active keyboard input focus.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Just to make clear... Polymorph introduced a MouseWheelEvent class, instances of which are generated from the HandMorph if the key combination matches what the VM currently passes (ctrl+up/down). These new events are handled based on mouse pointer location and not keyboard focus so providing mouse scrolling without disturbing the keyboard focus. Of course, should the VM's change to generate "proper" wheel events, much of Morphic handling is now already in place. So, with mouseClickForKeyboardFocus enabled the Gnome behaviour should apply, barring morphs deliberately changing keyboard focus without regard for that setting ;-) (which is where this all started...) Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, February 21, 2009 1:20 PM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Gary,
Of course :) You guys are doing a great job! I just replied to Sig, emphasizing the Gnome/Windows split on scrolling based on cursor position while leaving the focus alone. Gnome has it right. However, I would give priority to consistent focus before worrying about sending the wheel input where it belongs. Sounds like we need to add wheel events to the VM; then it should be easy to handle both (control-up/down for older vms, and wheel events doing exactly what is desired by the user).
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers [gazzaguru2@btinternet.com] Sent: Saturday, February 21, 2009 8:02 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Which is handled in Polymorph of course.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, February 21, 2009 3:59 AM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Concerning keyboard focus and mouse scroll. (sorry, if it was already noted in this discussion, i didn't read it fully).
VM does not have a mouse wheel events. Instead, it generates ctrl-up / ctrl-down key combinations. I think that this hack is the root of all problems: - if focus doesn't following the mouse, you need additional hacks in image to treat ctrl-up / ctrl-down keys to generate scroll events for morph which is currently under the mouse, not the morph which is currently having an active keyboard input focus.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Sig, The thing that caught my attention was keyboard shortcuts, but I mentioned the wheel as an example of something where some deviation from the mainstream might be in order. With the wheel, I frequently find myself expecting the input to follow the mouse cursor. Gnome does what I expect; it scrolls "under the mouse" and yet leaves focus where it was. There's another OS (will remain nameless) that is not quite as clever. However, I would far rather have the wheel input follow focus than suffer with focus following the mouse. Bill ---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Friday, February 20, 2009 10:59 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter Concerning keyboard focus and mouse scroll. (sorry, if it was already noted in this discussion, i didn't read it fully). VM does not have a mouse wheel events. Instead, it generates ctrl-up / ctrl-down key combinations. I think that this hack is the root of all problems: - if focus doesn't following the mouse, you need additional hacks in image to treat ctrl-up / ctrl-down keys to generate scroll events for morph which is currently under the mouse, not the morph which is currently having an active keyboard input focus. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Nevetheless, a simple preference for the new OB behaviour will settle the argument for all in the meantime. Let's move on. OB is getting there in terms of look and feel now.
Right. I added this preference now in the latest version of OB. It's called 'autoFocusForColumn', by default it's activated. David
David,
Keyboard up/down are events that can be translated into commands, and then "fired" up the hierarchy. It's been done this way for a long time. Very few custom components are in actually needed. Think of it as another incarnation (indeed literally in this case) of the old argument about composition vs. inheritance. Inheritance is wonderful, but in this case, it can/should be avoided. Plugging code into the correct places in a framework will avoid the need for the customized list. That is not to say that the OB lists are not needed - I do not know enough about them. However, a solid event/command framework would be hard pressed not to do the same thing, only better.
Commands serve a role somewhat like exceptions. The problem/need is noticed in one area, the message is put in the correct channel and reviewed until somebody knows what to do with it. The overhead is (Gary - disagree if you feel the need) not so severe as with exceptions because it is a much more focused task.
As an example, control-t for tests: you might also want to fire the same command from menus. Doing what I advocate makes that trivial. Dolphin does a great job of this kind of thing, right down to enabling/disabling commands vs. individual widgets.
This assumes that OB itself (as a top level component) take a role in making all of this work. But that's a good thing once you adapt to it.
In response to an earlier comment you made: there is always another way. Commands are the preferred one here - trust me.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger Sent: Friday, February 20, 2009 11:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi Bill,
Commands are a decoupling that allow the GUI to control how things get processed while allowing individual tools to control what happens when commands are processed. It's not direct, but it correct.
I agree with you here. But see, this change is not really about commands. Alex gave you an example where this change is useful in the context of commands. But this was not the motivating example for me to do this change, I was not even aware that it could also be useful in Alex' scenario involving commands. The scenario I had in mind does not really employ commands at all, but basic keyboard actions like key up, key down (see my first mail in this thread). Maybe you can look at those as commands too, but the action they perform is certainly dependent on the view in which they are meant to happen.
So there is more behind this than just "easing" the execution of commands.
David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 10:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi Bill,
but your approach to it is not a small change: you are moving GUI code into the tools, which is bad practice. I do not really understand what you mean with "tools" here. I moved this code to the Morphic subclass we use to represent pluggable lists in OB (a subclass of PluggableListMorph), so this is the GUI code used in the tool and IMO the only place where I could possibly move this GUI code into, namely into other GUI code. ;)
Please let Gary help you do this properly. Gary actually suggested me to do it like this. As I said, it's really the only way to realize this change so that it only affects the columns in OB, trust me.
To make the extent of the change clear: What it does is to give the columns in OB-based browsers the focus whenever the mouse is over them. This only affects columns, nothing else, in the OB browser, and certainly also no other browsers, tools, whatsoever not based on OB.
The question that remains is just whether people want a pref to enable/disable this changed behavior or not, I think. I don't have the impression that we need to discuss the implementation of this change.
I will answer separately to your other mail.
David
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Röthlisberger [squeak@webcitas.ch] Sent: Friday, February 20, 2009 9:17 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Hi
First of all, I did not authored this change. David did it. I guess this was a request emanated by a bunch of people. Yes.
Personally, the only reason why I am happy with the auto-focus, is by pressing Cmd-T to run tests. I find this quite convenient to simply accept a method, then move the moose to the column and press Cmd-T, without clicking. yes. Another scenario from Stef: Having a method selected in the method list, going with the mouse button to the first column while having selected the hierarchy button and press key up or down to conveniently browse the same method in super- or subclasses.
Although I do not see a scenario where auto-focus is a real problem, I do understand that David made an arbitrary decision without much consultation. Sorry about that. So, what do we do? Well, I did some "consultation" with Gary and Stef. But they left the decision to me, so I "decided" to be it like that for the moment to see how people react. I don't mind to, as Gary suggested, introduce yet another preference (there are already two related to this "auto-focus") saying whether one wants to ignore the mouseClickForKeyboardFocus preference in the browser's columns, although I personally think that such a preference is not needed as I can't imagine that this auto-focus for columns gets into the way too often (if at all). But if people want me to add such a pref, fine by me.
I don't think we want to start a much ado about nothing discussion about this small change. ;)
David
On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote:
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
I think we should have a protocol on how to solve this kind of conflicting position. We could vote maybe... I do not ming to have this behavior as optional, but I would like it to be set by default :-) Alexandre On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote:
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I've asked David if he would preference it... As for the mouse wheel, that does follow the mouse pointer so I was confused as to why anyone would want the keyboard focus to follow the mouse for OB columns irrespective of the mouseClickForKeyboardFocus preference. Each to their own (hence preference required). Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Friday, February 20, 2009 1:38 PM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I do not know what is mouseClickForKeyboardFocus I just feel that when putting the moose over a column, in which an item is selected, and pressing a shortcut for a command should execute the OB command. Am I missing something obvious? Cheers, Alexandre On 20 Feb 2009, at 15:05, Gary Chambers wrote:
I've asked David if he would preference it...
As for the mouse wheel, that does follow the mouse pointer so I was confused as to why anyone would want the keyboard focus to follow the mouse for OB columns irrespective of the mouseClickForKeyboardFocus preference. Each to their own (hence preference required).
Regards, Gary
----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Friday, February 20, 2009 1:38 PM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 20.02.2009, at 15:11, Alexandre Bergel wrote:
I do not know what is mouseClickForKeyboardFocus I just feel that when putting the moose over a column, in which an item is selected, and pressing a shortcut for a command should execute the OB command. Am I missing something obvious?
Would the selected textfield then loose the focus? That would be a bot annoying... (as "mouseClickFor.." exactly specifies that the focus only changes when you click). Marcus
Cheers, Alexandre
On 20 Feb 2009, at 15:05, Gary Chambers wrote:
I've asked David if he would preference it...
As for the mouse wheel, that does follow the mouse pointer so I was confused as to why anyone would want the keyboard focus to follow the mouse for OB columns irrespective of the mouseClickForKeyboardFocus preference. Each to their own (hence preference required).
Regards, Gary
----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Friday, February 20, 2009 1:38 PM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
Alexandre, Keyboard focus is an important concept, and Polymorph (or in general the window manager currently in use) needs to manage it. How about this: teach OB that control-t means run tests, and wash it through the normal hierarchy of keyboard handling - the mouse location is irrelevant at this stage. The control-t arrives where keyboard input goes: to the view with focus. There is an accepted way to do the next part: I _think_ it involves checking for a matching shortcut, but I honestly do not remember. Gary will know, or will find out within minutes. Failing that, I can consult my copy of the Borland Open Architecture Guide for its documentation on Object Windows; that gives an idea of how long these things have been done a certain way. IIRC, once identified as a shortcut, it walks up the view/command hierarchy until something knows what to do with it - in this case, OB would look for a selection in the relevant pane, and run tests. If you have no selection, then you will end up clicking and changing focus that way, which is fine. The approach outlined above should provide the behavior you want w/o distributing GUI management into individual tools. In fact, there is nothing to stop this code from using the current mouse location to find the "item under the cursor" and run tests on it. I would rather it not do that, but go for it if that's what you want. The point is that you do not need to work against Polymorph's focus management to get the behavior. Re anything you might be missing, consider me on a good typing day. People have been known to complain about the racket. There are faster typists, but I can do a pretty good test. I type words, not characters (I have to slow down to do the latter). If focus is grabbed "at random" because I bumped the mouse with my elbow (I've even seen cursors drift with no apparent motion of the mouse), a change of focus will result in (just guessing) three to five characters being sent to a list that will start trying to make selection to match characters before I can begin to react to it. Does that make sense? Bill ---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [alexandre@bergel.eu] Sent: Friday, February 20, 2009 9:11 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Automatic focus on column upon moose enter I do not know what is mouseClickForKeyboardFocus I just feel that when putting the moose over a column, in which an item is selected, and pressing a shortcut for a command should execute the OB command. Am I missing something obvious? Cheers, Alexandre On 20 Feb 2009, at 15:05, Gary Chambers wrote:
I've asked David if he would preference it...
As for the mouse wheel, that does follow the mouse pointer so I was confused as to why anyone would want the keyboard focus to follow the mouse for OB columns irrespective of the mouseClickForKeyboardFocus preference. Each to their own (hence preference required).
Regards, Gary
----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Friday, February 20, 2009 1:38 PM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter
Alexandre,
Can you give us an explanation or pointer to one? This sounds like something that Gary worked hard to stop from happening. I want you to have what you want from your image, and I need my future users to have what they will demand (loudly<g>). I am also convinced that there are things (e.g. mouse wheel input) that should "follow the mouse" without affecting keyboard focus, and this might be one of them, but referring to focus gives me the idea that keyboard input will go to the columns based on mouse position, and that (PLEASE!!!!!) needs to be optional - it drives me batty. I type quite fast, and if the input goes to what amount to commands instead of editing, it can get ugly.
There are some preferences that control behavior like this, and any such overrides should be conditional on one being set, or moved into the themes, probably as an aspect vs. implied by the theme choice. By the latter, I am assuming that you want Motif style mouse/focus behavior in any old theme you happen to choose. That's fine, but it should be optional or we are taking a step backward in feel.
Bill
---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [Alexandre.Bergel@inria.fr] Sent: Friday, February 20, 2009 5:04 AM To: Pharo Development Subject: [Pharo-project] Automatic focus on column upon moose enter
David, You're a hero! Thanks for OB-Enhancements-dr.305
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (9)
-
Alexandre Bergel -
Alexandre Bergel -
Damien Cassou -
David Röthlisberger -
Gary Chambers -
Igor Stasenko -
Marcus Denker -
Schwab,Wilhelm K -
Stéphane Ducasse