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