Bug 98290 - Better shortcuts for the Mac OS X platform
Summary: Better shortcuts for the Mac OS X platform
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha0+
Hardware: All Mac OS X (All)
: medium enhancement
Assignee: Yousuf Philips (jay)
QA Contact:
URL:
Whiteboard: target:5.2.0 target:5.3.0 target:5.2.0.1
Keywords:
Depends on: 92382 101736
Blocks: 42082 Shortcuts-Accelerators
  Show dependency treegraph
 
Reported: 2016-03-01 02:20 UTC by Yousuf Philips (jay)
Modified: 2016-08-26 12:44 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) 2016-03-01 02:20:18 UTC
In order for LibreOffice to feel more native to the Mac OS X platform, it needs to use similar shortcut keys as other apps and follow Apple's human interface guidelines on which shortcuts can and cant be used [1]. Some of this effort happened during the OOo days [2], but it wasnt completed, so i'll be continuing it and as i dont have a mac, i'll welcome input from mac users to suggest and test the new behaviour.

[1] https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/Keyboard.html

[2] https://wiki.openoffice.org/wiki/Mac_OS_X_Porting_-_Keyboard_Shortcuts
Comment 1 Yousuf Philips (jay) 2016-03-01 02:43:35 UTC
To get the ball rolling: https://gerrit.libreoffice.org/22794

Edit > Fullscreen - Cmd + Shift + J to Ctrl + Cmd + F
Tools > Spelling - F7 to Cmd + Colon
Tools > Options - None to Cmd + Semicolon
Comment 2 Mike Saunders 2016-03-10 12:23:07 UTC
Here's one I haven't seen on the spreadsheet, but would be good to have. In Apple's own apps, if you edit a file and press Cmd+Q to quit, this "Do you want to save changes?" dialog appears: http://imgur.com/zgKsxeX

Here, you can press Cmd+Backspace to choose the "Don't Save" option without having to click the button manually. It's a good time-saver and would be great to have in LO.
Comment 3 Yousuf Philips (jay) 2016-03-11 04:43:27 UTC
Thanks for the suggestion Mike, but that isnt something i can do, as the shortcuts i know how to modify are limited to when the document is active. It would be good to collect all the shortcuts that work in Apple's dialog and then submit an enhancement bug, so a dev can see if those shortcuts can be made active on mac in the dialog.
Comment 4 Yousuf Philips (jay) 2016-03-21 16:43:55 UTC
Ctrl + G as Find Next - https://gerrit.libreoffice.org/23407
Comment 5 Björn Michaelsen 2016-03-22 01:26:18 UTC
Do we really want to divert our keymaps per platform? This will be a documentation and UX nightmare -- esp. with all the video tutorials and such then being platform specific. See also: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/891539

And the discussion at: http://thread.gmane.org/gmane.comp.documentfoundation.libreoffice.ux-advise/189/focus=230

=> UX-Advise
Comment 6 Yousuf Philips (jay) 2016-03-22 12:21:25 UTC
(In reply to Björn Michaelsen from comment #5)
> Do we really want to divert our keymaps per platform?

The diversion of keymaps per platform began in the OOo days, as referenced in the description of this bug, so as long as shortcut keys can be reserved/recommended by the OS per platform, there will always be differences that would need fixing - e.g. F11 is assigned to the Styles & Formatting window/sidebar, but it is an OS reserved shortcut on Mac to show the desktop.

If we want the best user experience for users in which LibreOffice shortcuts integrate well with the OS, we would need to create keymaps for Windows, Gnome, KDE and Mac, as each of these have a different set of reserved/recommended shortcut keys. We currently have Windows/Linux shortcuts and Mac shortcuts, though many of the Mac shortcuts are similar to Linux Gtk desktop environment (Gnome 3/Unity/Mate/Cinammon/XFCE/LXDE) and some Windows shortcuts aren't equivalent on Linux KDE - e.g. Find & Replace is Ctrl+H on Windows and Ctrl + R on KDE.

https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts

> This will be a documentation and UX nightmare

As someone who works in documentation and UX, i dont see this as a nightmare. With documentation, work is ongoing to get it up to date and as long as the shortcut changes are documented, it will be easy to make the necessary changes in the help, similar to what we've done with string changes.

https://wiki.documentfoundation.org/Documentation/RecentStringChanges

When it comes to UX, users want LO to feel like a native app and if common shortcuts in an OS map to a different function in LO, then LO doesnt feel as integrated, just like what is seen in the launchpad.net link.

> -- esp. with all the video tutorials and such then being platform specific.

As we had different shortcuts between Windows/Linux and Mac OS, just like we have menu bar differences (e.g. Windows/Linux has Tools > Options and Mac has LibreOffice > Preferences), so there will always be platform specific video tutorials for different OSes, just like we have language specific video tutorials.

> See also:
> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/891539
> And the discussion at:
> http://thread.gmane.org/gmane.comp.documentfoundation.libreoffice.ux-advise/
> 189/focus=230

I've seen both those links in the past when i suggested F11 be changed to fullscreen (bug 83467) and the F11 discussion is currently going on in bug 98333.

As previously mentioned in the design mailing list on the 1st of March, the ongoing work i'm doing to improve shortcuts on Mac can be found here.

https://docs.google.com/spreadsheets/d/198zpaE2SKD0MIQUmSKb-s9vVCZy5dsdLg5JXhJ82iHg/edit?usp=sharing
Comment 7 Björn Michaelsen 2016-03-24 15:57:19 UTC
unblocked gerrit changes, discussed at ESC today:
>    + What about these platform-specific keymapping changes (Bjoern)
>      e.g. https://bugs.documentfoundation.org/show_bug.cgi?id=98290#c5
>       + do we have some consensus on when to be crossplatform,
>         what to be plaform-integrated?
>       + Mac - different bindings: (Kendy)
>          + Mac has platform-specific F11 etc.
>            + not grauitous change.
>          + best to discuss with Jay.
>       + project needs to watch large-scale UI change (Thorsten)
>          + tension between: OS style guide vs. cross-plat consistency (Michael)
>          + expect design to balance that.
>       + already have some Win not working vs. Linux (JMux)
>          + have bug reports.
Comment 8 Commit Notification 2016-05-09 10:09:56 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=418982797f9bd2b2e9e5e47f81ba5041c91d6a0c

tdf#98290 Cmd + G as Find Next shortcut for Mac and Gnome

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2016-05-09 12:04:50 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e8ab8d1ea86d2cadaeed05d14b21d14d23667913

tdf#98290 New shortcuts for fullscreen, spellcheck and options (Mac)

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2016-05-31 16:55:01 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3e14a07a909439fa012e2831c1a163c527b07d50

tdf#98290 New Mac shortcut for fullscreen for all apps

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Commit Notification 2016-06-02 10:46:25 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b4ce1cf3be51900b43d913df205c1325862e739&h=libreoffice-5-2

tdf#98290 New Mac shortcut for fullscreen for all apps

It will be available in 5.2.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Tor Lillqvist 2016-06-02 11:28:58 UTC
Is the "full-screen" you talk about here LO's own such, or the OS X one? Note that sadly they are orthogonal. Which is a UI disaster of course. 

One can make a LO window go full-screen using the green bubble on the title bar, or use View:Full Screen. They need not be in sync.

Then to further complicate matters, there is also the OS X 'maximise window' (or whatever they call it) thing, that can be toggled by double-clicking the title bar. This state is also not coupled with the two others. Should it be? No idea. Anyway, one can end up with a LO window that is full-screen from LO's point of view but where one has double-clicked the title bar to make it 'unmaximise'.

As I have said earlier in other bug reports, I think we should just remove the current hack to "support" OS X full-screen mode from the code. It is a somewhat barebones quick hack and not at all well thought out and/or tested, and the interaction with LO's own full-screen concept is unclear.
Comment 13 steve -_- 2016-06-02 11:59:49 UTC
Tor: you think it's that complicated? Imo

Maximise window = not fullscreen related
Fullscreen (ctrl cmd F) is identical to fullscreen triggered via the green bubble.

That does not sound complicated to me.

I agree that having LO own fullscreen concept and OS X fullscreen concept colliding is a pita. So you suggest to remove OS X fullscreen in favor of LO's own concept?
Comment 14 Tor Lillqvist 2016-06-02 12:37:01 UTC
Surely it is confusing when one easily can get into a state where LO thinks it is full-screened but the actual window is not full screen at all?

Ideally it's LO's own full-screen concept that should be removed (or merged with the handling of the OS X full-screen concept). Having both is a disaster. But as there aren't any developers around that would have resources to actually work on this, it would be simpler to just kill the enabling of OS X's full-screen mode.