February 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problem with the OB debugger

by Dale Henrichs

StÃ©phane, What did the method look like? I just tried putting halts into a method and was able to proceed and step across the second halt. Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | Hi | | today I was giving lectures with the pahro-dev image and its OB- | debugger ad I noticed that | I could not have two halts else after proceeding the first one I got a | | resume I do not what | and I could not see the other halt. | Is it only me? | | Stef | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 20, 2009

Re: [Pharo-project] Problem with the OB debugger

by Schwab,Wilhelm K

Stef, I had not, but (I think) just did and it worked as expected. See attached and let me know. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Friday, February 20, 2009 1:55 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Problem with the OB debugger did you tried in different methods? Stef On Feb 20, 2009, at 7:45 PM, Schwab,Wilhelm K wrote: > Stef, > > So far, it might be just you??? I tried the following in 10236 and > can proceed from the first halt (either on the notifier or in the full > debugger) and see the second. > > Have I matched your scenario? I've even tried going elsewhere in the > callstack and been ok. In fact, I would prefer the debugger to pick > an earlier frame in most (all?) situations; e.g. it selects the #halt > method rather than the sender, which is what Dolphin has lead me to > expect. > > Bill > > > > DoubleHale>>tryMe > > 2 + 3. > self halt. > 4+5. > self halt. > > " > DoubleHalt new tryMe. > " > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of StÃ©phane Ducasse > Sent: Friday, February 20, 2009 1:29 PM > To: Pharo Development > Subject: [Pharo-project] Problem with the OB debugger > > Hi > > today I was giving lectures with the pahro-dev image and its OB- > debugger ad I noticed that I could not have two halts else after > proceeding the first one I got a resume I do not what and I could not > see the other halt. > Is it only me? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 20, 2009

Re: [Pharo-project] Problem with the OB debugger

by StÃ©phane Ducasse

did you tried in different methods? Stef On Feb 20, 2009, at 7:45 PM, Schwab,Wilhelm K wrote: > Stef, > > So far, it might be just you??? I tried the following in 10236 and > can proceed from the first halt (either on the notifier or in the > full debugger) and see the second. > > Have I matched your scenario? I've even tried going elsewhere in > the callstack and been ok. In fact, I would prefer the debugger to > pick an earlier frame in most (all?) situations; e.g. it selects the > #halt method rather than the sender, which is what Dolphin has lead > me to expect. > > Bill > > > > DoubleHale>>tryMe > > 2 + 3. > self halt. > 4+5. > self halt. > > " > DoubleHalt new tryMe. > " > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of StÃ©phane Ducasse > Sent: Friday, February 20, 2009 1:29 PM > To: Pharo Development > Subject: [Pharo-project] Problem with the OB debugger > > Hi > > today I was giving lectures with the pahro-dev image and its OB- > debugger ad I noticed that > I could not have two halts else after proceeding the first one I got a > resume I do not what > and I could not see the other halt. > Is it only me? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 20, 2009

Re: [Pharo-project] Problem with the OB debugger

by Schwab,Wilhelm K

Stef, So far, it might be just you??? I tried the following in 10236 and can proceed from the first halt (either on the notifier or in the full debugger) and see the second. Have I matched your scenario? I've even tried going elsewhere in the callstack and been ok. In fact, I would prefer the debugger to pick an earlier frame in most (all?) situations; e.g. it selects the #halt method rather than the sender, which is what Dolphin has lead me to expect. Bill DoubleHale>>tryMe 2 + 3. self halt. 4+5. self halt. " DoubleHalt new tryMe. " -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Friday, February 20, 2009 1:29 PM To: Pharo Development Subject: [Pharo-project] Problem with the OB debugger Hi today I was giving lectures with the pahro-dev image and its OB- debugger ad I noticed that I could not have two halts else after proceeding the first one I got a resume I do not what and I could not see the other halt. Is it only me? Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 20, 2009

Re: [Pharo-project] Automatic focus on column upon moose enter

by StÃ©phane Ducasse

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(a)anest.ufl.edu> > To: <Pharo-project(a)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(a)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(a)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(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David >> RÃ¶thlisberger [squeak(a)webcitas.ch] >> Sent: Friday, February 20, 2009 10:33 AM >> To: Pharo-project(a)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(a)lists.gforge.inria.fr >>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David >>> RÃ¶thlisberger [squeak(a)webcitas.ch] >>> Sent: Friday, February 20, 2009 9:17 AM >>> To: Pharo-project(a)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(a)lists.gforge.inria.fr >>>>> [pharo-project-bounces(a)lists.gforge.inria.fr >>>>> ] On Behalf Of Alexandre Bergel [Alexandre.Bergel(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 20, 2009

[Pharo-project] Problem with the OB debugger

by StÃ©phane Ducasse

Hi today I was giving lectures with the pahro-dev image and its OB- debugger ad I noticed that I could not have two halts else after proceeding the first one I got a resume I do not what and I could not see the other halt. Is it only me? Stef

Feb. 20, 2009

Re: [Pharo-project] Automatic focus on column upon moose enter

by Schwab,Wilhelm K

Gary, Sounds good on both fronts. Bill -----Original Message----- From: pharo-project-bounces(a)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(a)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(a)anest.ufl.edu> To: <Pharo-project(a)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(a)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(a)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(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David > RÃ¶thlisberger [squeak(a)webcitas.ch] > Sent: Friday, February 20, 2009 10:33 AM > To: Pharo-project(a)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(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David >> RÃ¶thlisberger [squeak(a)webcitas.ch] >> Sent: Friday, February 20, 2009 9:17 AM >> To: Pharo-project(a)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(a)lists.gforge.inria.fr >>>> [pharo-project-bounces(a)lists.gforge.inria.fr >>>> ] On Behalf Of Alexandre Bergel [Alexandre.Bergel(a)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(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 20, 2009

Re: [Pharo-project] Automatic focus on column upon moose enter

by Damien Cassou

On Fri, Feb 20, 2009 at 6:26 PM, Gary Chambers <gazzaguru2(a)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

Feb. 20, 2009

Re: [Pharo-project] Automatic focus on column upon moose enter

by Gary Chambers

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(a)anest.ufl.edu> To: <Pharo-project(a)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(a)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(a)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(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David > RÃ¶thlisberger [squeak(a)webcitas.ch] > Sent: Friday, February 20, 2009 10:33 AM > To: Pharo-project(a)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(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David >> RÃ¶thlisberger [squeak(a)webcitas.ch] >> Sent: Friday, February 20, 2009 9:17 AM >> To: Pharo-project(a)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(a)lists.gforge.inria.fr >>>> [pharo-project-bounces(a)lists.gforge.inria.fr >>>> ] On Behalf Of Alexandre Bergel [Alexandre.Bergel(a)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(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 20, 2009

Re: [Pharo-project] About Collections-Strings-pc.5 in PharoInbox

by Marcus Denker

On 20.02.2009, at 17:59, Damien Cassou wrote: > Hi, > > I've just seen somebody commited Collections-Strings-pc.5 to fix the > #asSignedInteger method. This method has already been fixed in one of > the very last pharo versions. > > This mcz should probably be moved out of PharoInbox. > done -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Feb. 20, 2009