User:Ismael

From Apache OpenOffice Wiki
Revision as of 18:06, 5 November 2006 by Ismael (Talk | contribs)

Jump to: navigation, search

Developper infos

Name: Ismael MERZAQ

IRC Nickname: Ismael


Current work

I'm working in implementing the key accelerators in the native menus (like Cmd+N for new document instead of ctrl+N in the X11 version).


Introduction

The purpose of this page is to present my work. As I have been contribuiting for few time, i have only worked on the key accelerators in the native menu.


Apple Documentation and References

Apple carbon reference about menus: [1]

Key accelerators

Short introduction: presenting the basis

The function which interests us is
void AquaSalMenu::SetAccelerator( unsigned nPos, SalMenuItem* pSalMenuItem, const KeyCode& rKeyCode, const XubString& rKeyName ) 
  • nPos is the menu item index, but nPos is 0 to n based whereas the carbon API we use for ooo macport is from 1 to n+1 e.g. for the first element nPos=0, and his carbon index will be 1
  • SalMenuItem* pSalMenuItem is a pointer to the menu item we want to add key accelerator
  • const KeyCode& rKeyCode is the keycode of the accelerator. We can get the keycode with rKeyCode.GetCode() and the key modifier(s) (like cmd, shift, ... for Mac OS) with rKeyCode.GetAllModifier()
  • const XubString& rKeyName is not used for the MacOs port

Implementation

We will use the SetMenuItemModifiers function to chose the modifier(s) of the key accelerator like cmd, shift, alt... and we'll set the key accelerator with two different function depending of the situation: the SetMenuItemCommandKey function for visible key accelerator (like for the N of Cmd+N) and the SetMenuItemKeyGlyph function for non visible characters (like for F1, F2,... or space).

Setting the key accelerator

The difficulty is that the OOo keycodes are different of the ASCII keycodes used in Carbon. For example: A is 65 in ASCII but in OOo it's 512 (defined in Key.hdl) So we have to translate from ooo codes to ascii, but the order of the characters are not exactly the same as ASCII so we translate only by intervals. We obtain this code:

if ((ncode>=KEY_A) && (ncode<=KEY_Z)) {
    nresultcode=ncode-KEY_A+'A';
}
else if ((ncode>=KEY_0) && (ncode<=KEY_9)) {
    nresultcode=ncode-KEY_0+'0';
}

We do the same thing for non visible characters but instead of using the ascii code of the given character we use its carbon value.

else if((ncode>=KEY_F1) && (ncode<=KEY_F12)) {
    nresultcode=kMenuF1Glyph+ncode-KEY_F1; // kMenuFnGlyph=kMenuF1Glyph+n only for n<13 then it should be processed for each case
}
else if((ncode>=KEY_F13) && (ncode<=KEY_F15)) {
    nresultcode=kMenuF13Glyph+ncode-KEY_F13; //kMenuF13Glyph=0x87 and kMenuF12Glyph=0x7A
}
else if(ncode==KEY_SPACE) {
    nresultcode=kMenuSpaceGlyph; 
}

Then we only have to add the accelator to the menu:

  • For the non visible characters: The syntax of SetMenuItemKeyGlyph is:
OSErr SetMenuItemKeyGlyph (
   MenuRef inMenu,
   SInt16 inItem,
   SInt16 inGlyph
);

so we use it like this:

SetMenuItemKeyGlyph (
    mrMenuRef, //is the reference to the menu
    nPos+1, // for the reason of using nPos+1 instead of nPos see the short intro
    nresultcode
    );
  • For visible characters: The syntax of SetMenuItemCommandKey is:
OSStatus SetMenuItemCommandKey (
   MenuRef inMenu,
   MenuItemIndex inItem,
   Boolean inSetVirtualKey,
   UInt16 inKey
);

so we use it like this:

SetMenuItemCommandKey (
    mrMenuRef,
    nPos+1,
    0,
    nresultcode
    );


Problems and know bugs

Key accelerators used both by OOo and MacOS X

The first problem is that some key accelerators are already used by mac os, and so macos catch them and do the associated action, and ooo don't see them. For example, when we press F9 in openoffice (native version or X11 version), the fields aren't refreshed because the macos function exposé is launched and so catch the key accelerator (to refresh the fields go to tools>refresh>fields in the menu (or something like that, as I have a french version of ooo, i translate the menu texts in english and so it's not always the good translation)). What we have to do is to change the conflictual key accelerators. Here are these conflictual key accelerators:

  • OOCalc:
    • F9 ==> shows exposé instead of recalculing the cell content (tools>cell content>recalc)
    • F12 ==> shows dashboard instead of doing Data>Plan>Group

Following Apple Human Interface Guidelines in menus

The second problem which is not really a problem is that we have to change some key accelerators if we want to respect the Apple Human Interface Guidelines (AHIG) (Apple Human Interface Guidelines and mostly AHIG for key accelerators and menus and for menu exemples ) Here's a list of key accelerators which doesn't correspond to Apple Human Interface Guidelines:


  • The key accelerator used in OOo refers to another function in AHIG:
    • cmd '-' (hyphen):
      • in OOo: adds a "conditional hyphen" ("tiret conditionnel" in french)
      • AHIG: Decrease the size of the selected item (equivalent to the Smaller command).
  • The function uses in OOo a key accelerator which is different than the one specified in AHIG
    • SpellCheck:
      • in OOo: F7
      • AHIG: cmd+';' (semicolon) and should be in the edit menu
    • Preference window:
      • in OOo: in the menu Tools>options without key accelerator
      • AHIG: key accelerator cmd+',' (comma), and located in “The Application Menu”
    • Opening Help:
      • in OOo: F1
      • AHIG: cmd+? (question mark)
    • Redo command:
      • in OOo: cmd+Y
      • AHIG: shift+cmd+Z
    • non breaking space
    • Save as
      • in OOo: no key accelerator
      • AHIG: shift+cmd+S
    • Close window
      • in OOo: in the window menu with the key accelerator and the text "close the window" and in the file menu without key accelerator and with the text "close"
      • AHIG: in the file menu with the text "close" and with the key accelerator cmd+W
Personal tools