> 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: [email protected] > [mailto:[email protected]] On Behalf Of David > Röthlisberger > Sent: Friday, February 20, 2009 11:25 AM > To: [email protected] > 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: [email protected] >> [[email protected]] On Behalf Of David >> Röthlisberger [[email protected]] >> Sent: Friday, February 20, 2009 10:33 AM >> To: [email protected] >> 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: [email protected] >>> [[email protected]] On Behalf Of David >>> Röthlisberger [[email protected]] >>> Sent: Friday, February 20, 2009 9:17 AM >>> To: [email protected] >>> 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: [email protected] >>>>> [[email protected] >>>>> ] On Behalf Of Alexandre Bergel [[email protected]] >>>>> 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 >>>>> _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
