On 2012-12-03, at 10:02, Goubier Thierry <[email protected]> wrote:

> Le 03/12/2012 13:31, Camillo Bruni a écrit :
>>> Well, it's allmost there. The only thing that I didn't manage to push was 
>>> the removal of the global, class-linked maps (it was rejected)... This is 
>>> the only step missing for your vim shortcuts to work.
>> 
>> Maybe I can revive the discussion here, sadly it died on the tracker :/.
> 
>> I would really love to see your changes in the image!
>> However it slightly (changes/breaks depending on the viewer :P) some 
>> focus-cycling in certain tools.
> 
> There is two different issues :
> 
> vim-like shortcuts and focus.
> 
> First, vim-like (and emacs, and whatever); this requires cutting off matching 
> of the default shortcuts (since those often conflicts). These defaults being 
> non configurable, Sean (for vim) and I (for my dynamically loaded / matched 
> to current menu shortcuts), had to disconnect from matching the default 
> class-based keymaps by on-the-fly patching of a target Morph KMDispatcher :() 
> Hugly hack, this one.

I think that should be fine. I remember I did something similar once with 
Keymapping (in the early days). Doru needed the very same for Moose, so we 
tried to make it work. I ended up with creating a subclass of KMDispatcher or 
so, which has a local key-mapping. So there are more or less elegant solutions 
to this problem (making it work is the main priority :P)

> Second, keyboard focus navigation. First, what I did is the following : 
> correct a bug or two in the Morphic based focus navigation code. And, second, 
> move the focus navigation shortcuts to Keymapping. Nothing else.

yeah this is how it is supposed to be, no special trickery needed otherwise. 
neat!

> However, this exposed one fact about Morphic: that the way to add submorphs 
> is LIGT (Last In Goes to Top i.e: in front of the previous submorphs). This 
> is great for a drawing editor, and bad for an UI design tool, such as Spec. 
> So Spec loads in an apparent reverse order (at least relative to the focus 
> order), and this is what you see.

right

>> Is there a way to come up with a more or less compatible things as the focus 
>> list?
>> Aka a nice and simple interface on top of your changes to achieve the same 
>> thing?
> 
> Yes. Just have Spec use on:do: (or load the right keymap) for focus change, 
> instead of using eventHandler. I do believe this change is just around the 
> corner...
> 
> Once this is done, any focus order you set in Spec will apply first when 
> focus tabbing.
> 
> However, you may then see design faults : if you forget one element in your 
> focus ordering in Spec, you will never manage to focus it by the keyboard. 
> Whereas the Morphic one will always tab through all elements whatever way you 
> build the GUI.

right

> IMO, the best would be Spec being able to order submorphs correctly and to 
> then rely on the Morphic focus code. But there must be a good reason for Spec 
> not doing it. I just don't know why? I tried changing a bit Spec for that 
> (changing the default ordering where I could see it, then changing a few 
> Specs here and there to make sure the GUI would build and tab right) and 
> couldn't find anything wrong with it, but I just checked on a few GUI samples.

I think the only thing with major focus issues was the refactoring-changes 
browser. 
- do a class-rename with the refactoring menu
- try to tab through the changes in the list

> (This is also because the focus switch code in Morphic is a lot shorter than 
> the Spec one, and I tend to believe the shorter the better (and no 
> duplication). But that's just me:)).

I think I don't know enough of the internal details, but I saw the 2 sides of 
the discussion:
- Ben said that it won't work without an explicit focus-order list
- I loaded your code, and roughly all tools still worked :) (minor issues with 
the changes browser for instance)

Conclusion: 
- Your approach seems to make sense as an approximation of the common case, 
which is important. 
- But we need custom control in certain cases.

>> We desperately need this refactoring, and if we don't use it, just because 
>> of the focus list, I think it will take another year until they make it into 
>> the image :(
> 
> I thought it was integrated. I'll check. It is integrated; what I guess is 
> missing is the Spec override.

http://code.google.com/p/pharo/issues/detail?id=6736
http://code.google.com/p/pharo/issues/detail?id=6657


thanks for looking into it!

Reply via email to