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.
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.
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.
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.
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.
(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:)).
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.
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
