Apache OpenOffice (AOO) Bugzilla – Issue 92224
MacOSX keyboard shortcuts not quite there
Last modified: 2012-10-10 09:27:51 UTC
I noticed that the beta2 release fixed some of the MacOSX keyboard shortcuts to be more compliant with Apple's human interface guidelines. For example, the cmd+arrow keys now correctly jump to the beginning and end of a line. Likewise, option+arrow keys now correctly jump over words. The issue is now that the rest of the guidelines are still not working and cause even more painful experience than before, specifically when using the shift modified. For example, cmd+shift+arrow does not select to the beginning and end of a line. option+shift+arrow does not select words. Instead, I have to change between using option+arrow for movement and cmd+shift+arrow for selecting.
confirm shift problem
reassign
SBA: See also issue 93326 ("Auto complete Ctrl-Tab not working on Mac OSX")
*** Issue 94545 has been marked as a duplicate of this issue. ***
In Calc, Cmd-Left and Cmd-Right don't move the cursor to the beginning and ending of the cell contents when editing. Using Option-Left and Option-Right to skip words doesn't work either.
*** Issue 95571 has been marked as a duplicate of this issue. ***
*** Issue 94622 has been marked as a duplicate of this issue. ***
*** Issue 95854 has been marked as a duplicate of this issue. ***
*** Issue 96142 has been marked as a duplicate of this issue. ***
*** Issue 96184 has been marked as a duplicate of this issue. ***
*** Issue 93749 has been marked as a duplicate of this issue. ***
http://www.brighton.ac.uk/centrim/Members/gjp4/ooo/qa/92224 - some screen shots of Apple Keyboard Viewer, British keyboard, with various keys depressed.
http://www.diigo.com/annotated/90babb46cfd3b6af110f90daf3504b78 highlights a key point from 'Apple Human Interface Guidelines: The Keyboard': > When used with other keys, the Option [alt] key produces special symbols.
see also issue 93249 fixed in CWS vcl97
*** Issue 96498 has been marked as a duplicate of this issue. ***
please verify in CWS vcl97
Verified with cws vcl97 = ok
Shift–Option–Right Arrow should extend > To the end of the current word, then to the end of the next word In OOoDEVm39, extension occurs _beyond_ the end of the word (includes white space) The norm is to _not_ include the white space beyond the end of the word. Shall we re-open this issue 92224 or would you prefer a separate issue? Apple Human Interface Guidelines: The Keyboard: Extending Text Selection With the Shift and Arrow Keys <http://tinyurl.com/apple-hig-ooo-93749>
Personally, I think the whole thing is a mess. I downloaded a new version (DEV300m37) a couple of weeks ago. It indeed suffers from the bug described above by _grahamperrin_. But the keyboard shortcuts are still puzzling: (apple)-(left), (right) goes to the beginning/end of line (shift)-(apple)-(left), (right) selects a word (alt)-(left), (right) - skips to next word (shift)-(alt)-(left), (right) - does nothing sorry, but cannot we have some consistency in this? This is just ridiculous.
<http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fvcl97> if I understand correctly shows the integration milestone as m39 @ stepank DEV300m37 is not most recent. You may download for example DEV300_m39 from <http://download.openoffice.org/300/index.html> and test again. @ developers I should say, thanks! Whilst I have not tested comprehensively, keyboard-oriented use of DEV300_m39 *does feel* immensely better, more Mac-like in many ways. The white-space-beyond-the-word issue seems to also bug my Microsoft Office Word 2008, but that should not detract from proper behaviour according to Apple HIG. Best, Graham
@ grahamperrin: mea culpa -- I downloaded DEV300m39 and the problem is solved in this build, i.e. shift properly modifies the behaviour of other keys. However, someone changed the way how selected text looks -- instead of being inverted, it is covered by light blue. Hmm. is that supposed to make it visible better?
Cmd-Left and Cmd-Right still don't work when editing cell contents in Calc: Home and End must be used there. I tested with DEV300m39 (Build:9378). So how can this issue be marked fixed? Or is there a different issue for Calc?
*** Issue 98827 has been marked as a duplicate of this issue. ***
I just downloaded DEV300m40 (Build:9381). confirmed that cmd+left/cmd+right and alt+left/alt+right don't operate at all in spreadsheet cells. confirmed fixed on the start of line/eld of line/prev word/next word shortcuts. confirmed fixed on the select to start of line/select to end of line/select next word/select prev word shortcuts. The word movement/selection shortcuts don't operate the same as, say, TextEdit. alt+right in OOo always takes the cursor to the start of the next word, whereas alt+right in TextEdit takes the cursor to the end of the current word. Same applies for the word selection shortcuts (alt+shift+right). The start of word shortcuts work the same in OOo as in TextEdit.
@OC: Please take a look.
> The word movement/selection shortcuts don't operate the same as, > say, TextEdit. alt+right in OOo always takes the cursor to the > start of the next word, whereas alt+right in TextEdit takes the > cursor to the end of the current word. Same applies for the word > selection shortcuts (alt+shift+right). AFAICT that echoes the comment Mon Jan 26 17:53:01 +0000 2009
> someone changed the way how selected text looks -- instead of > being inverted, it is covered by light blue. Hmm. is that supposed > to make it visible better? That is now issue 98924, colour of highlight of selected text is not a good match for the user's system-preferred colour
> confirmed that … alt+left/alt+right don't operate at all in > spreadsheet cells. Issue 96184 (treated as a duplicate of this issue 92224) was: >> alt-shift-left alt-shift-right alt-shift-up alt-shift-down >> (arrow keys) on Mac OS X MUST NOT manipulate tables In DEV300m40 (Build:9381) I find that alt-up alt-down manipulates tables. alt-up and alt-down on Mac OS X MUST NOT manipulate tables. Apple HIG for the keyboard http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGUserIn put/chapter_12_section_3.html#//apple_ref/doc/uid/TP30000361-CECDGEDJ http://tinyurl.com/apple-hig-the-keyboard-mov state that these key combinations are for simply moving the insertion point. > Cmd-Left and Cmd-Right still don't work when editing cell contents > in Calc > confirmed that cmd+left/cmd+right … don't operate at all in > spreadsheet cells. Command–Left Arrow = To the previous semantic unit, typically the beginning of the current line, then the previous unit Command–Right Arrow = To the next semantic unit, typically the end of the current line, then the end of the next line
In the input line of Calc in OOo-dev 3.0.0 DEV300m41 (Build:9383) alt-right alt-left alt-shift-right alt-shift-left command-right command-left — all fail.
Apple HIG: Window Behaviour: Minimizing and Expanding Windows http://tinyurl.com/apple-hig-windows-minim-expand http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGWindo ws/chapter_18_section_5.html#//apple_ref/doc/uid/20000961-TPXREF25 > When the user clicks the minimize button, double-clicks the title > bar, or presses Command-M, the window minimizes into the Dock. In OOo-dev 3.0.1: Command-M fails to minimise windows in Base, Calc, Draw Impress and Writer.
> In OOo-dev 3.0.1: > > Command-M fails to minimise windows in Base, Calc, Draw Impress and Writer. Correction; the bug was noticed first whilst running OOo from OOo-Dev_DEV300_m41_MacOSXIntel_install_en-US.dmg (I tried command-M in Calc, Impress and Writer) then reaffirmed in current release 3.0.1 (not a developer snapshot).
Can you please create separate issues for your complaints ? It won't really help making this issue into the one big "there are still bugs in OOo" issue. In fact the only thin I can guarantee is that this issue will be closed as verfied since the addressed changes are now obviously in the master. The Cmd-Alt-<whatever> things not quite choosing what you want (be that an additional space or a table) are enhancements/changes for the appropiate applications as they should react differently to specific keys. The Cmd-M for minimize is a separate missing functionality, you can assign that one to me.
closing
Sorry, I was instructed that the whole key assignment stuff for MacOS will be reworked by (this) issue 92224. I do prefer separate issues :)
For the benefit of other readers/reporters: based upon the more symptoms reported in this issue, we now have: issue 98949 issue 98950 issue 98951 issue 98952 issue 98953 issue 98954 issue 98955 issue 98956 Regards Graham