On Fri, Nov 4, 2011 at 1:16 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Where can I find documentation on Keymapping (if it exists)?

Hmmm, If you load the #bleedingEdge (which is pretty stable right now), there are several examples in the categories:

Keymapping-Morph
Keymapping-Editors
Keymapping-Tools
...

Also, most of the classes have comments, but I think I have to review them so far :).
�

Here are the basics I have so far:
* the available set of shortcuts is per-class
* a shortcut is created by creating a builder method (similar to World Menu
registration) annotated with <keymap>
* shortcuts are grouped into categories
* categories (not individual shortcuts) are attached to Morph classes via
KMBuilder>>attachShortcutCategory:to:
* the system is updated when "KMPragmaKeymapBuilder uniqueInstance" resets
itself via #reset (but see problems below)

Questions:
* What is the purpose of naming shortcuts?

Hmm, mainly, to bind a shortcut to a setting.� And nothing else by now...� So I use it as a kind of id :/.� Maybe someone has a better approach... I was about to review it with Mariano tomorrow.
�
* Why are shortcuts held by categories as named entries and separately as
keymaps?

This is an idea I took from the original keymappings.� I classify shortcuts in categories so you can:

- attach a category to a specific class (letting its instances handle those keymaps)
- attach a category to a specific instance (the same as above but in the instance level :) )

You can also attach a single shortcut in a morph like:

someMorph on: aShortcut do: [ some task ]

But this last (lets say) annonimous shortcut, can't be put into a setting.
�

There seems to be a problem with updating shortcuts (esp. changing existing
ones):
* It seems that when an existing named shortcut is modified, eventually
KMShortcut>>shortcutHasChangedIn:by: is called, but this method does
nothing, so the shortcut never gets updated. Why is this? It seems like a
bug.

Hmm, strange.� There are two implementations of this method in my image.� One in KMShortcut and one in KMNoShortcut, one does nothing (on purpose with a comment :P) but the other has an implementation :/...
�
* When a <keymap> method is saved in OB, KMPragmaKeymapBuilder>>reset is
called twice - once via AnnouncementSubscription>>deliver:, and once via
KMPragmaKeymapBuilder>>event:

Hmm, I didn't knew this one :)
�
* Because KMRepository class>>reset is never called, it becomes very dirty
if shortcuts are repeatedly edited. For example, create a shortcut named
"myShortcut" with Cmd+D in Category "Test", now change its name and accept
the code. You will have two shortcuts with the same key combination. Now
change to Cmd+E and accept again. You will have three shortcuts, even though
you have only one specified in your builder method...

So it seems to me to keep integrity in the shortcuts, either:
* "KMRepository reset" when anything is changed, and start from scratch
* or, improve KMPragmaKeymapBuilder>>reset's ability to keep the system
clean.

I did it on purpose right now.

The problem with resetting the KMContainer, is that you lose the customizations you did in the settings right now.

Thinking aloud, maybe It would be good to provide two resets:

- shallow reset.� That resets the shortcuts but tries to remember the customizations done in the settings.�� This one can be done every time you modify a <keymap> annotated method.

- deep reset.� That just resets everything.� You have to know that you are loosing everything here :).
�

Thanks for the feedback :)
Guille


Sean

--
View this message in context: http://forum.world.st/Keymapping-Questions-tp3990667p3990667.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.