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" <[email protected]> > To: <[email protected]> > 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: [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 >>>>> >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
