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
> [hidden email]
> 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: [hidden email]
> [[hidden email]] On Behalf Of Gary Chambers
> [[hidden email]]
> Sent: Saturday, February 21, 2009 8:02 AM
> To: [hidden email]
> 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" <[hidden email]>
> To: <[hidden email]>
> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of David
> Röthlisberger
> Sent: Friday, February 20, 2009 11:25 AM
> To: [hidden email]
> 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: [hidden email]
>> [[hidden email]] On Behalf Of David
>> Röthlisberger [[hidden email]]
>> Sent: Friday, February 20, 2009 10:33 AM
>> To: [hidden email]
>> 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: [hidden email]
>>> [[hidden email]] On Behalf Of David
>>> Röthlisberger [[hidden email]]
>>> Sent: Friday, February 20, 2009 9:17 AM
>>> To: [hidden email]
>>> 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: [hidden email]
>>>>> [[hidden email]
>>>>> ] On Behalf Of Alexandre Bergel [[hidden email]]
>>>>> 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
>>>>>