Le 03/12/2012 15:23, Camillo Bruni a écrit :
On 2012-12-03, at 10:02, Goubier Thierry <thierry.goub...@cea.fr> 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)
Yes, but, still, the code to find the right KMDispatcher to replace is
ugly, especially for PluggableTextMorph (since you have not one, but two
KMDispatcher to replace).
Once done, it works perfectly. You just keep that knowledge somewhere to
be able to recreate it (PluggableTextMorph... Hum... Two KMDispatcher to
find and replace; MorphTreeMorph... one KMDispatcher instance to replace
:) ).
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
And what is happening then? Do you tab out 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
There is maybe something about Spec component-based approach and
composing focus navigation there. The next focus code in Spec is fairly
complex when you look at it from the composition angle.
Another issue is : do you need to have Spec handling the focus
navigation for Spec to work well on multi targets (Morphic, Amber,
HTML5, etc...) ? This would be a very important question for me if this
multi-toolkit aspect is one of the design goal for Spec.
- I loaded your code, and roughly all tools still worked :) (minor issues with
the changes browser for instance)
And, since then, you were bypassing Spec focus order allmost everywhere :)
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.
Yes. This is possible in both (either with the Morphic one or the Spec
focus order) by setting the focus yourself when you want it. Just call
takeKeyboardFocus on the Morph you want.
You just have to take care that you don't throw the focus code in an
endless loop by shortcutting the order (that was the bug in Morphic : it
would loop forever because of a send navigation key to an owner Morph
somewhere :( ).
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!
It's a pleasure to work in Pharo, you know that feeling :)
Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
