Apache OpenOffice (AOO) Bugzilla – Issue 93685
Keyhandler does not get ctrl / alt modifier bits on MacOS X
Last modified: 2013-02-24 21:01:08 UTC
Hi Dunno if this is by intention, but as it is impossible to use Ctrl and Alt on Mac as Modifiers to assign Macros etc. to on 3.0rc1, I tried to adapt the AltKeyHandler macro suite for a mac. But there is a show stopper: IMHO the keyhandler does not get the right modifier bits in the KeyEvent parameter. Current situation: The shift key delivers 1 (correct), and the Apple key delivers 2 (on PCs this corresponds to the Ctrl key). 4 does never appear, except when you use Fn together with a key which has a second meaning (like Fn-u which corresponds to the 4 of the numeric keypad on powerbooks). Should-be: The shift key delivers 1, and the Apple key delivers 2. Alt delivers 4. Ctrl delivers 8 (or vice versa, I suggest to use the bits as they appear in other mac applications, dunno which ones they are). Fn should not deliver any modifier bits, as in my understanding, it is only a modifier key to simulate keystrokes coming from keys that do not exist on the smaller powerbook keyboard, but exist on a normal Mac keyboard, so when you press Fn-4, the pattern should be the same as when you press 4 on the numerical keyboard of a normal Mac keyboard. Or is this a misunderstanding, and applications do not get alt / ctrl status using modifier bits from the OS? How else would they determine the status of these keys...? Use the AltKeyHandler macro suite (google to find), install the KeyHandler using the SetupAltKeyHandler function (or by correctly installing the suite) and look at the KeyHandler_keyPressed function to reproduce the problem. Thanks, R.
Andreas, could you help Rollom? Thanks Kay
This doesn't seem to be scripting related in the first place. ab->pl: Does this belong to your area? Please have a look.
Lots of Alt key combinations are used by MacOS system wide for specific functions (e.g. alt-cursor keys to move the cursor wordwise). So the answer is: it depends on the key combination. Do you have a specific method of reproduction ?
Thanks for your answer. Press alt-u, for instance, and you don't get a modifier bit. The field just stays zero. Press apple-u and you get bit 2 set. Looks like you never get modifier bits for ctrl or alt. Do normal mac apps not get modifier bits either? Or are they being swallowed somewhere in OOo?
alt-u is consumed by the Mac's input method (which depends on the currently active input language), e.g. if you press it repeatedly in a german locale, a unicode 168 (some kind of bullet) is inserted. Since this is interpreted by the input method you don't get a key event at all but an extended input event, inserting that character. ctrl events won't work, they are reported as third modifier, but that is not a valid definition in the UNO API yet (there is also no UI to configure this e.g. in tools->customize). That was one of the reasons to report Cmd as MOD1 (which is Ctrl on other platforms) since the Cmd key on the mac takes the meaning that is used on other platforms with ctrl.
Well, looks like we won't be able to fix this then. Not supporting the third modifier (Alt on PCs, Ctrl on Mac) looks like a severe own goal to me, as you're not able to clone the MS Office UI on OOo that way. Like most of the people on this planet I have to use Word and Writer in parallel, and that way you can't really get used to a keyboard layout as you have to switch back and forth all the time. IMHO things like these are the main reasons why OOo will never be able to get a serious market share compared to MS Office (for the same reason the undoubtedly more efficient Dvorak keyboard layout will never replace qwerty/z...). Using AltKeyHandler I could at least partially fix the problem. Not being able to solve it on Mac is a darn pity...
Agreed. Please note that we will support the Ctrl key, just currently there is no UI for it implemented (see Tools->Customize->Keyboard). This will come in one of the next versions when the framework team has resources for that implementation again. The clashes with the Alt (aka Option) key are regreattable, but there will always be clashes on different systems. One could also think about dispatching the shortcuts BEFORE going through the input method, but currently this is not feasible, we'll need to have a marking mechanism for currently used key events then - which is not the case, key events at the moment are dispatched and someone evaluates them or not, which is why we have to filter them through the system's input method first. So there is no immediate solution, we need to restructure key event handling through the applications before this works better. In light of this I'll flag this as an enhancement and hope we can do these changes through the 3.x tree.
There is MOD3 nowadays for Ctrl in the awt UNO API, so what would be needed is an extension of Tools->Customize for the configuration. Generally it would also be nice to have a method to query "is this an accelerator" for a key event so that keys would not have to pass the input method and similar things (see also e.g. issue 59435 and issue 50547). AFAIK framework should have a complete list of accelerators.
see also issue 105416