Hannes Hirzel wrote:

>
>
> Here I have a suggestion. Instead of the tab user interface I would 
> prefer just having a list at the left like in the preferences browser 
> as one cannot read what is written on the tabs. However this is just 
> an minor issue.


I agree.  It isn't so minor since being able to read the category names 
seems quite important.  Generally if you raise the editor on a specific 
morph (rather than using "KeymapEditor open") then the category list is 
smaller and readable.  I'm not sure which direction I will go with this 
but the "left list" idea seems like one worth thinking about.

>
>
>
>> Anyway, if all goes well you'll notice that many of the popup menus 
>> now show the Keymapping syntax for key bindings (<m-x> instead of 
>> just x, for example).  If you want to change a binding, hold your 
>> mouse over the morph, press <c-k> (control-k) and the keymap editor 
>> will open with all of the categories relevant to that morph.  Change 
>> the entries as you see fit.  You can also save and load keymaps.  If 
>> you have any problems with Keymapping, please let me know.  I plan to 
>> release this version and would like to squash any bugs before they 
>> get into the wild.
>
>
>
> I didn't get this. For example I tried a TextMorph and a StringMorph 
> and wanted to change the font size. In the menus I do not see the 
> keyboard shortcuts. What I would like to do is just to click on a 
> Morph and then use a keyboard shortcut to enlarge the font size 
> instead of fiddeling around with a huge menu.
>
> Is this working in 3.7?


No.  Right now only the right-click popup menus reflect keyboard 
shortcuts.  No effort was made to get this to work in the Morph menu.  
The best way to find the shortcuts in this case is to raise the 
KeymapEditor on that morph.  If there is wider interest in Keymapping I 
would be willing to go to some lengths to correct this.  Note that in 
general my algorithm finds the correct shortcut for pluggable morph's 
popup menus but not always.  For example, open a workspace, for example, 
and raise the right click menu.  You'll see the shortcut sequences.  
Same thing in a Browser.  If you look at the UI code for KeymapManager 
(and related classes) you'll see a model for creating menus and 
associating actions with the menu items.  My hope is that Keymapping 
finds wide (maybe even base) adoption and that developers switch to 
using the mechanism for creating popup menus.  Then, the correct 
shortcut could always be found and displayed in the menu.

Now, a second problem.  I loaded into a fresh image and noticed that my 
conversion of the existing shortcuts converts the <c-k> sequence for 
TextMorph which shadows the "Default" category's entry so you won't get 
the KeymapEditor if you use that sequence over a TextMorph.  The reason 
I hadn't noticed this is that I removed that sequence from my personal 
TextMorph keymap.  I'm going to fix the conversion script so that <c-k> 
is not converted.  In the mean time you can either remove it from your 
TextMorph keymap yourself (note it is listed as <c-pgup> since that is 
how the SqueakVM translates it) or go to the Default category and change 
the sequence that raises the KeymapEditor.  Finally, in general when a 
morph's keymap shadows <c-k> you can raise an inspector on the morph and 
then evaluate "KeymapEditor forMorph: self".

What I would like to do is add a halo icon and/or a morph menu item to 
raise the KeymapEditor on a morph.  I haven't done it b/c there is no 
reasonable method to add a menu item to all morphs except overriding the 
base version which is done in several packages so my override is bound 
to be, well, overridden.  I'm a little reluctant to add to the halo 
since it seems to be the place for more "honored" tools than my lowly 
keymapper.

David