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: [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

Reply via email to