Apache OpenOffice (AOO) Bugzilla – Issue 82684
AQUA PORT : writer : ^+SHIFT+J conflicts with kotoeri
Last modified: 2009-07-20 15:20:02 UTC
Hello, on writer, aqua port (680mm233, french version), pressing ctrl+Shift+J starts/stops fullscreen (as well as apple+shift+J). However, ctrl+shift+J is already used by the kotoeri input method in order to switch to hiragana input. Have a good day
Another reason to only support apple+<shortcut key> and not have both apple+ and control+
I think every key combination for input method should be handled at the first priority. For example, AquaSKK (http://aquaskk.sourceforge.jp/) input method uses Control-j to switch input mode, however, current OpenOffice.org Mac will change justification of text alignment instead of input mode change in AquaSKK. Following change for salframeview.mm will do that, but as it seems there is no way to check the key combination for input method is consumed in NSTextInputMethod, the key combination like C-j with AquaSKK will be handled twice (input mode change and then text alignment of OOO). @pl:, what do you think? ndex: salframeview.mm =================================================================== RCS file: /cvs/gsl/vcl/aqua/source/window/Attic/salframeview.mm,v retrieving revision 1.1.2.11 diff -u -r1.1.2.11 salframeview.mm --- salframeview.mm 1 Nov 2007 13:48:47 -0000 1.1.2.11 +++ salframeview.mm 4 Nov 2007 07:38:19 -0000 @@ -461,6 +461,9 @@ mpFrame->mnLastEventTime = static_cast<ULONG>( [pEvent timestamp] * 1000.0 ); mpFrame->mnLastModifierFlags = [pEvent modifierFlags]; + NSArray* pArray = [NSArray arrayWithObject: pEvent]; + [self interpretKeyEvents: pArray]; + bool bHandleCommandKey = mpFrame->mpMenu ? false : true; if( (mpFrame->mnLastModifierFlags & NSControlKeyMask) || ( (mpFrame->mnLastModifierFlags & NSCommandKeyMask) && bHandleCommandKey ) @@ -472,9 +475,6 @@ return; } - NSArray* pArray = [NSArray arrayWithObject: pEvent]; - [self interpretKeyEvents: pArray]; - mbInKeyInput = false; } }
The whole idea of calling checkSpecialCharacters in keyDown was that some keys should not be swallowed by the input manager. If we pass key events to the input manage first, then we should scrap checkSpecialCharacters wholesale. At the moment with your patch if you press Ctrl-shift-j you get into full screen mode and back again, because the event is dispatched twice - unless you happen to have the input method which swallows that key event. Since it simplifies the code, I'd vote to remove the block bool bHandleCommandKey = mpFrame->mpMenu ? false : true; if( (mpFrame->mnLastModifierFlags & NSControlKeyMask) || ( (mpFrame->mnLastModifierFlags & NSCommandKeyMask) && bHandleCommandKey ) ) { // note: checkSpecialCharacters sets mbInKeyInput to false as a side effect // if the event is consumed if ( [self checkSpecialCharacters:pEvent] ) return; } Any conflicts that occur between input manager and our shortcuts will have to be solved somehow by OOo using other shortcus.
> At the moment with your patch if you press Ctrl-shift-j you get into full > screen mode and back again, because the event is dispatched twice - unless > you happen to have the input method which swallows that key event. Hmm, actually I didn't consider that case. Thanks for the explanation. > Since it simplifies the code, I'd vote to remove the block I also think it's good idea. But this may cause some key combinations like Control-q disabled because doCommandBySelector will be not called in such key combination.
I see. Actually doCommandBySelector only works if there is another clash with a system key binding, right ? In which case the OOo binding would be preferred.
Anyway we should find a solution and fix this in aquavcl04
> Actually doCommandBySelector only works if there is another clash with a > system key binding, right ? Yes, here is an Apple's doc (http://developer.apple.com/documentation/Cocoa/Conceptual/InputManager/Concepts/KeyBindings.html). From this document, it doesn't seem that there is a way to configure the key-binding from application side. > In which case the OOo binding would be preferred. Sure. I couldn't understand way Apple set the return value of interpretKeyEvents _void_. Anyway we should find a solution about this, however, other applications like Safari, Camino, iTerm seems to also suffer from this problem. For example, With AquaSKK, Control-j causes both mode change in Input Method and application event simultaneously...
For the moment we will pass all keyDown events to the input manager first. Ctrl-Q is something we don't need since on Mac it is Command-Q anyway. Similar is true for copy/paste. We will need to think harder again if we find a shortcut that is not available by its Command eqeuivalent anymore. In the long term I'd like (cross platform BTW, gtk and X suffer from problems in the same area) the shortcuts to be registered in the native code so we can explicitly know which key is an accelerator used by OOo and which not, so at least we could decide which key event would be ours. Which is no solution to clash problem either, of course ;-)
Thanks for a nice decision :)
I made one last exception for ctrl-alt-shift-d; this does not come to insertText or doCommandBySelector via the input manager (and is quite helpful in debugging). However for the moment this is the only exception. If you have an idea where that vanishes to, we could remove the exception again.
please verify in CWS aquavcl04
Verified in CWS aquavcl04
This issue is closed automatically and wasn't rechecked in a current version of OOo. The fixed issue should be integrated in OOo since more than half a year. If you think this issue isn't fixed in a current version (OOo 3.1), please reopen it and change the field 'Target Milestone' accordingly. If you want to download a current version of OOo => http://download.openoffice.org/index.html If you want to know more about the handling of fixed/verified issues => http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues