Comment #14 on issue 6656 by
[hidden email]: Move all shortcuts
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656Ok. As I said to Sean, I need your suggestions and wisdom for some changes
to Keymapping.
I'll set some vocabulary first, and you will be able to check if I have
understood Keymapping in the first place:
Shortcuts in Keymapping are grouped in keymaps. Keymaps may have sub
categories, to cope with platform differences : #Unix, #Windows, #MacOS,
#all (it looks nice and forward thinking!).
KMDispatcher is in charge of trying to match a key event (received by the
Morph which has the focus(remember that, it has consequences)) to a
shortcut. It cycles through targets to do so, each target having one or
more keymap associated. KMDispatcher is one of the first matcher seen by a
Morph (which is very good, thanks for the guy who did that!). If a shortcut
is not matched by KMDispatcher, it falls through in Morphic other key
handling code (Important point). Morphic may move key events between
morphs, giving a chance (chance ? more like bad luck when that happens) for
another morph and KMDispatcher to match the event.
KMDispatcher targets belong to three categories :
- static targets : global keymaps linked to the morph class. The use of
static targets is #deprecated in the KMDispatcher code.
- targets : named keymaps (from the global KMRepository) that are
associated with a KMDispatcher instance with a call to attachCategory:
- per instance target : keymaps setup by calling on:do: on the KMDispatcher
instance
Initially, KMDispatcher would randomly iterate over all those targets to
match a shortcut. I changed that to force the following order: per instance
target, targets, static targets (but since targets is a set, if you load
multiple targets in a KMDispatcher with overlapping shortcuts, it's random
order again).
Now, there is a need for some applications to have fine control over which
shortcuts are active, and static targets gets in the way of that, since
they are allways checked. On the contrary, targets and per instance target
may be resetted by doing KMDispatcher reset.
So my choice is :
1) Add a flag to KMDispatcher to disallow, if true, static targets
2) Remove the static targets and make reset erase both targets and per
instance targets.
1) works, but is a bit of a kludge (and is visible to applications since
they have to learn to use it). Compatibility with code that rely on static
targets is perfect. This is the one I implemented for now in the slices.
Total control by an application is:
aKMDispatcher perInstanceOnly: true. "Switching to vim mode"
aKMDispatcher reset. "Yep, but targets are not resetted."
aKMDispatcher on: $d, $d do: [self eraseLine].
2) Break compatibility with code relying on static targets : is there any
such code ? Nautilus doesn't I believe, TextEditor and SmalltalkEditor (the
two non-Nautilus global keymaps) are targets (non-static) for
PluggableTextMorph. Once done, total control by an application is simply :
aKMDispatcher reset.
aKMDispatcher on: $d , $d do: [self eraseLine]
So which one would you prefer ?
_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Locked
