Description: I use Dvorak keyboard layout with the QWERTY command variant (Dvorak-QWERTY). This lays out keys in the Dvorak arrangement but reverts to QWERTY layout when the command key is pressed, so that frequently used commands (CMD-X - Cut, CMD-V - Paste etc) can be used with the regular keys sighted. All other Mac applications respect this layout. However, when trying to use this keyboard layout in Libreoffice (any subcomponent) the QWERTY command layout is not respected. Thus in a document, if I press CMD-X to cut text, Libreoffice responds with the action for CMD-Q (Quit application). Pressing CMD-B in an attempt to Bold text will respond to the CMD-X (Cut text) command. This would be correct behaviour for Dvorak standard layout but does not respect the QWERTY Command variant. This should be considered a bug as it breaks expected behaviour. Steps to Reproduce: 1. Open a text document. 2. Switch to Dvorak - QWERTY keyboard layout. 3. Highlight some text then attempt to cut, paste, bold or otherwise interact with it with the CMD-<key> combinations. 4. Observe that the expected actions do not occur and instead the standard Dvorak key combinations result instead. 5. Switch back to a standard Dvorak layout. 6. Repeat step 3. 7. Observe the commands are responding in exactly the same way. 8. Switch to a native (e.g. US English QWERTY layout) 9. Repeat step 3. 10. Observe the commands respect the visible keyboard layout. Actual Results: With Dvorak-QWERTY as a keyboard layout: Selecting text and pressing CMD-X to Cut text results in a Quit action. Selecting text and pressing CMD-B to Bold text results in the Cut action. Selecting text and pressing any CMD-<key> combination results in the action associated with the underlying Dvorak layout instead of the visible QWERTY layout. Expected Results: With Dvorak-QWERTY as a keyboard layout: Selecting text and pressing CMD-X to Cut text should result in the Cut command. Selecting text and pressing CMD-B to Bold text should result in the Bold command. Pressing the CMD-<key> combination should respect the Dvorak-QWERTY variant layout and produce the command associated with the visible key. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 6.3.2.2 Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU threads: 8; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded
I'm assuming we need an actual physical Dvorak keyboard to try and reproduce this to confirm and not just the OS system setting ? Unfortunately, I have never used such a keyboard, and I don't know of anyone else helping out in QA on Mac that might. I can well believe that the shortcuts get screwed up though. There are already several Mac-keyboard specific bugs that attest to this with various keyboard/language combinations: See for example https://bugs.documentfoundation.org/show_bug.cgi?id=98290
> All other Mac applications respect this layout Have you tried them all?
Sounds to me like one of those "Doctor, doctor" type of situations.
(In reply to Alex Thurgood from comment #1) > I'm assuming we need an actual physical Dvorak keyboard to try and reproduce > this to confirm and not just the OS system setting ? Unfortunately, I have > never used such a keyboard, and I don't know of anyone else helping out in > QA on Mac that might. > > I can well believe that the shortcuts get screwed up though. There are > already several Mac-keyboard specific bugs that attest to this with various > keyboard/language combinations: > > See for example > https://bugs.documentfoundation.org/show_bug.cgi?id=98290 No, that's the point of Dvorak-QWERTY. It's designed for people who want to touch type Dvorak layout on a QWERTY keyboard. I'm using it on a British QWERTY Macbook Pro. You can test it out on any standard keyboard just by switching it in Keyboard->Input Sources.
(In reply to Tor Lillqvist from comment #2) > > All other Mac applications respect this layout > > Have you tried them all? Of course I did. Why do you think it took me so long to report? Is all seriousness, I suppose I mean all Mac applications which confirm to the OS X human interface guidelines.
(In reply to Tor Lillqvist from comment #3) > Sounds to me like one of those "Doctor, doctor" type of situations. I'm missing that reference. Can you explain further?
(In reply to Alex Thurgood from comment #1) > I'm assuming we need an actual physical Dvorak keyboard to try and reproduce > this to confirm and not just the OS system setting ? Unfortunately, I have > never used such a keyboard, and I don't know of anyone else helping out in > QA on Mac that might. > > I can well believe that the shortcuts get screwed up though. There are > already several Mac-keyboard specific bugs that attest to this with various > keyboard/language combinations: > > See for example > https://bugs.documentfoundation.org/show_bug.cgi?id=98290 Here is reference to a similar issue on another Mac application which solved it by handling hotkeys via NSMenuItem: https://github.com/godotengine/godot/issues/4386
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to bugzilla from comment #4) > > No, that's the point of Dvorak-QWERTY. It's designed for people who want to > touch type Dvorak layout on a QWERTY keyboard. I'm using it on a British > QWERTY Macbook Pro. > > You can test it out on any standard keyboard just by switching it in > Keyboard->Input Sources. OK, thanks, I will give it a try when I'm next back in front of my master build machine which has an Apple wifi keyboard attached. Like I said, given that we already have x number of still open reports against keyboard shortcut issues for the Mac version of LibreOffice, there is a fairly high probability (although one never knows) that even if confirmed, it won't be receiving attention anytime soon, unless someone with your setup volunteers to fix it, as it is pretty obscure in the grand scheme of things and macOS devs capable and having the inclination to fix it are very thin on the ground (but clearly welcomed, if you happen to know any that would like to contribute).
I can confirm this, also present on 3.3 Lowering importance as this is very much an edge case Version: 6.4.0.0.alpha1+ Build ID: 80109586e6cb6d3e2e0a53a9079c3125ec9b8368 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Dear bugzilla, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still present Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 9bfc42015acd6ae3475ab7927ccc006507cc38a2 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: Skia/Raster; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
This actually works now! With "Dvorak QWERTY" the shortcut keys are as "normal", while with "Dvorak" my follows Dvorak Version: 24.2.0.0.beta1 (AARCH64) / LibreOffice Community Build ID: 5f390384195b7264c6e52add9e90a39790285249 CPU threads: 10; OS: macOS 14.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded