swapping control and caps lock keys makes Menu preference, Apps Menus (except Firefox) and Team Monitor do weird things

[karmak]

Haiku hrev28735, IBM R52. I use a French keymap and "Alt" as default shortcut in Menu Preferences.

Creating a custom French keymap (attached) with keymap command works like expected : i can swap control and caps lock. Apps (SpicyKeys, Terminal, StyledEdit and others) act like I expect them to, e.g. pressing CapsLock acts as Control was pressed. "Alt" remains active as the default shortcut (Alt-W closes windows, and so on). Cool !

BUT: Opening Menu Preferences shows that "Control" is my default shortcut, which is definitely false. I didn't change it from Haiku defaults, and "Alt" is the active one, refering to reality of what happens on my computer.

Checking back "Alt" in the Menu preference makes the thing more weird : When checked, Control (CapsLock key) doesn't work any more (pressing CapsLock-C in Terminal doesn't send Control-C signal), CapsLock (Control key) still works (Caps LED goes on/off), and "Alt" key doesn't do anything (no way to send Control-C signal in Terminal).

Checking back "Control" as shortcut in Menu preference doesn't solve the situation : Alt-C sends Control-C signal in Terminal, Control key works as CapsLock (expected behaviour), but CapsLock key doesn't produce Control ; I can't do Alt-W and Haiku shortcuts, no way.

To definitely solve the situation, I must reload my custom keymap. From then, initial situation is restored, e.g. Control and CapsLock are swapped, Alt is my Haiku shortcut, and Control is displayed as default Haiku shortcut in Menu preferences, which doesn't correspond to reality.

Note : I always load/reload my keymap from the binary one. Trying to load it from the human-readable form does nothing but hang in the terminal. I must send Control-C signal and load the binary one.

Note2: binary keymap is simply the human-readable form obtained with keymap -c.

[karmak]

French keymap with Control and CapsLock swapped

[karmak]

I should add that with my Control and CapsLock swapped, the only way to bring up Team Monitor is to press CapsLock-Alt-Suppr (the key labelled Control on my keyboard), e.g. Team Monitor doesn't seem to be sensible to swapping. Bringing it up like this obviously makes the caps led state change.

I can understand Team Monitor is brought up by a different mechanism as the rest of the desktop, to be able to run it in situations where the desktop or deskbar is hung, but this seems inconsistent with the keymap I loaded.

[korli]

TeamMonitor calling keys are in fact hard coded to Ctrl+Alt+Del. Menu also only checks against hard coded keys Ctrl and Alt.

[korli]

The TeamMonitor part is fixed in hrev28782.

[karmak]

And with hrev28797 (build fixed for Keymap*), I can use my swapped Control-Alt-Suppr to bring up Team Monitor. Thanks !!

[karmak]

missing part of diff for Keymap.cpp

[karmak]

please anyone can commit the keymap.diff attachment ; it's the missing part for my last patch, making it complete. thanks.

[anevilyak]

Updated patch applied in hrev28800 - thanks!

[karmak]

Curiously enough, with my swapped Control and Caps Lock, every Haiku app shows "Ctrl"-* as shortcuts in theyr menus, except Firefox which correctly displays "Alt"-*.

Perhaps the problem lyes in the interface kit and not just the "Menu" preferences applet.

I'm currently digging in the code to try to correct "Menu".

[karmak]

Diff for Menu Preference applet to detect and correctly Invert modifiers

[karmak]

Attached menu.diff, which fixes Menu preferences applet. It hardcodes only Alt key, and doesn't car of what value is set to Control key. It just inverts the 2 modifiers when conditions are met to.

Added a TODO entry inside to explain what to do, in case someone want to definitely fix the Applet in case user sets whatever keyboard key to Alt (Command).

I will now dig into app_server/input_server/whatever to understand why native apps have Control shown in their menu when Alt is set, but not Firefox. But not now (currently 2AM here ; going to sleep).

[anevilyak]

Replying to karmak:

I will now dig into app_server/input_server/whatever to understand why native apps have Control shown in their menu when Alt is set, but not Firefox. But not now (currently 2AM here ; going to sleep).

The answer is quite simple: Firefox does not use the native menus. It implements all its own widgets in its XUL toolkit using low level drawing and input primitives, and as a consequence, has an entirely internal method for determining what the menu accelerator key is. For native menus, the reason for this is that for whatever reason currently a hardcoded keycode check is used to determine which of two (also hard-coded) bitmaps to draw (see src/kits/interface/Menu.cpp circa line 352). Ideally this should probably be changed to a) draw it using vector primitives so it can scale properly to different menu font sizes, and b) use the keycode definitions in InterfaceDefs.h to determine what symbols are mapped to the command and control keys and draw what's actually mapped. Care needs to be taken here though, as menu commands can require a combination of B_COMMAND_KEY, B_CONTROL_KEY and/or B_SHIFT_KEY together to be invoked as well, so all of those would need to be checked depending on what the modifiers mask of the menu item is set to. Hope that helps.