Bug 98290 (Shortcuts-Mac) - [META] Better shortcuts for the Mac OS X platform
Summary: [META] Better shortcuts for the Mac OS X platform
Status: NEW
Alias: Shortcuts-Mac
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: Not Assigned
URL: https://developer.apple.com/macos/hum...
Whiteboard: target:5.2.0 target:5.3.0 target:5.2.0.1
Keywords:
Depends on: 43680 92382 108911 115284 119425 34704 101736 114858 115361 118422
Blocks: MacOS-Wishlist Shortcuts-Accelerators
  Show dependency treegraph
 
Reported: 2016-03-01 02:20 UTC by Yousuf Philips (jay) (retired)
Modified: 2018-10-04 23:25 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
After pressing Cmd+Shift+F (1.30 MB, image/jpeg)
2018-01-28 14:58 UTC, Tor Lillqvist
Details
Still in LO "full-screen" mode, but after moving (!) the window (1.40 MB, image/jpeg)
2018-01-28 15:00 UTC, Tor Lillqvist
Details
Still in LO's own "full-screen" mode, with window resized even (1.73 MB, image/jpeg)
2018-01-28 15:02 UTC, Tor Lillqvist
Details
After clicking the green bubble, in the macOS full-screen mode (1.24 MB, image/jpeg)
2018-01-28 15:05 UTC, Tor Lillqvist
Details
Just FYI: Still in the macOS full-screen mode, but with cursor at top of screen (1.31 MB, image/jpeg)
2018-01-28 15:08 UTC, Tor Lillqvist
Details
Frankenmode example (1.43 MB, image/jpeg)
2018-01-28 15:15 UTC, Tor Lillqvist
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 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) (retired) 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) (retired) 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) (retired) 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) (retired) 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.
Comment 15 Xisco Faulí 2017-09-11 08:40:15 UTC
Dear developer,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Comment 16 Tor Lillqvist 2018-01-28 14:42:12 UTC
I find it somewhat sad that the change in comment #9 are implemented without checking how confusing it ends up working in the end. Steve, you say "Fullscreen (ctrl cmd F) is identical to fullscreen triggered via the green bubble." It very obviously is not. Did not actually check? Did you not see any difference in look or behaviour?

I really think making the Ctrl+Cmd+F shortcut toggle LO's own "full-screen" mode was a mistake. That shortcut should mean the same as clicking the green bubble on the title bar. It does not. We should have kept the old shortcut to avoid confusing the two concepts.

(The green bubble toggles the macOS full-screen state, where the app window being full-screened is on a desktop of its own and fills the screen completely, with the title bar visible only if you move the cursor to the top. This is completely different from LO's own "full-screen" mode, where the window stays on the same desktop where it was. The title bar is somehow hidden sure, but the window is actually not locked at full screen size. One can drag it smaller, and then end up in a truly horrible and confusing state.)

I repeat, I think we should just remove the current hack to "support" macOS full-screen mode from the code. I will do that when/if I can find inspiration. Then just LO's own "full-screen" thing will remain.

Sure, that is far from ideal. What *should* be done, if somebody had the inspiration and resources, would be to get rid of LO's own full-screen mode completely on macOS, and just implement the macOS full-screen mode properly.
Comment 17 Tor Lillqvist 2018-01-28 14:58:01 UTC
Created attachment 139409 [details]
After pressing Cmd+Shift+F

LO's own "full-screen" mode, which is not at all implemented as the real macOS full-screen mode, but still uses its shortcut. Note that the document title bar ("Untitled 1") with the three bubble buttons (of which the middle, yellow one, is greyed out) at the left is still visible. The menu bar is hidden, sure.

I have taken the screenshots I am attaching using my phone camera as all effects I want to point out were not visible when taking screenshots the normal way;)
Comment 18 Tor Lillqvist 2018-01-28 15:00:00 UTC
Created attachment 139410 [details]
Still in LO "full-screen" mode, but after moving (!) the window

Even while in LO's own "full-screen" mode, it is possible to drag the window from the title bar. Of course, in a proper full-screen mode that should not be possible.
Comment 19 Tor Lillqvist 2018-01-28 15:02:31 UTC
Created attachment 139411 [details]
Still in LO's own "full-screen" mode, with window resized even

Here I then also resized the document window a bit smaller. The button used to exit LO's own full-screen mode is now floating happily by its own. Very silly state.
Comment 20 Tor Lillqvist 2018-01-28 15:05:28 UTC
Created attachment 139412 [details]
After clicking the green bubble, in the macOS full-screen mode

Here I have clicked the green bubble in the title bar. The title bar and menu bar are hidden, as they should be, but the app window does not fill the screen, as can be seen from where the mouse cursor is. (In this state the window can naturally not be moved or resized, it really is "full-screen" (except that it leaves a black band at the top).
Comment 21 Tor Lillqvist 2018-01-28 15:08:11 UTC
Created attachment 139413 [details]
Just FYI: Still in the macOS full-screen mode, but with cursor at top of screen

When in the macOS full-screen mode, moving the cursor to the top of the screen shows the menu bar and title bar, that hide the top part of the app window and whatever GUI widgets it might have there. That is OK and as expected.
Comment 22 Tor Lillqvist 2018-01-28 15:15:20 UTC
Created attachment 139414 [details]
Frankenmode example

By mixing up sequential switch into and out of LO's full-screen mode, and in to and out of the macOS full-screen mode, one can end up with beautiful states like this, where the window is in macOS full-screen mode but actually is much smaller than the screen.
Comment 23 Tor Lillqvist 2018-01-28 16:15:02 UTC
The code in vcl/osx/salframeview.mm that handles dealing with the macOS full-screen behaviour seems in the -(id)initWithSalFrame: (AquaSalFrame*)pFrame instance method of the SalFrameWindow class seems a bit confused: It sets the bool bAllowFullScreen to a value:

>     bool bAllowFullScreen = (SalFrameStyleFlags::NONE == (mpFrame->mnStyle & (SalFrameStyleFlags::DIALOG | SalFrameStyleFlags::TOOLTIP | SalFrameStyleFlags::SYSTEMCHILD | SalFrameStyleFlags::FLOAT | SalFrameStyleFlags::TOOLWINDOW | SalFrameStyleFlags::INTRO)));
>     bAllowFullScreen &= (SalFrameStyleFlags::NONE == (~mpFrame->mnStyle & SalFrameStyleFlags::SIZEABLE));
>     bAllowFullScreen &= (mpFrame->mpParent == nullptr);

And then it checks that in an if statement:

>    if( bAllowFullScreen && [pNSWindow respondsToSelector: setCollectionBehavior])
>    {

But inside that if block, where bAllowFullScreen clearly is true, it checks it again:

>         const int bMode= (bAllowFullScreen ? NSWindowCollectionBehaviorFullScreenPrimary : NSWindowCollectionBehaviorFullScreenAuxiliary);

Doesn't really increase one's confidence in this code (from 2012)...

Anyway, clearly it is by now pointless to do that respondsToSelector dance as we only support macOS >= 10.9 by now. We can just use the collectionBehavior property directly. (It as introduced in 10.7.)

Also, it seems that since 10.11 the default is for windows to be full-screenable (in the macOS sense) by default, and to disallow that, one needs to set the collectionBehavior property to NSWindowCollectionBehaviorFullScreenNone . I tried that, and then the green button turned into one with a plus sign in it, and clicking it "maximises/unmaximises" the window (the same as double-clicking the title bar). Probably this is better than having the green button invoke the macOS full-screen behaviour that LO is not really prepared to handle sanely?
Comment 24 Tor Lillqvist 2018-01-28 17:35:57 UTC
See https://gerrit.libreoffice.org/#/c/48796/ . It would be great if somebody running OS X 10.9 or 10.10 could test this.
Comment 25 Tor Lillqvist 2018-01-28 17:39:32 UTC
Re: comment #5:

Björn, a concept like "full-screen mode" most likely is present in some way on all major desktop environments already. Does LibreOffice's home-grown full-screen concept interact nicely and sanely with all those (except the macOS one)? I doubt it. I doubt it is "normal" for apps to have a floating single-button dialog to get out of full-screen mode in any desktop environment, for instance. Instructions and especially video tutorials related to this will always be platform-specific (and in danger of losing their relevance relatively quickly, in a few years, as platforms evolve).
Comment 26 Yousuf Philips (jay) (retired) 2018-01-28 17:59:37 UTC
Tor: I've opened bug 115284 to deal with mac fullscreen shortcut and behaviour, so please add your comments about it there, so we can keep this bug focused on all mac shortcuts. thanks.
Comment 27 Paul Oranje 2018-03-06 14:45:10 UTC
Calc in LO 6 maps Cmd+` to toggle view formulas; in Writer and other subapps this key behaves in the normal platform expected mode: move to next open window.
Comment 28 Maarten Brouwers 2018-06-28 09:43:11 UTC
(In reply to Paul Oranje from comment #27)
> Calc in LO 6 maps Cmd+` to toggle view formulas; in Writer and other subapps
> this key behaves in the normal platform expected mode: move to next open
> window.

Experiencing the same bug as Paul Oranje. Should we open a separate bug for this issue? (since *this* is a 'META' bug?)
Comment 29 V Stuart Foote 2018-06-28 13:18:22 UTC
(In reply to Maarten Brouwers from comment #28)
> (In reply to Paul Oranje from comment #27)
> > Calc in LO 6 maps Cmd+` to toggle view formulas; in Writer and other subapps
> > this key behaves in the normal platform expected mode: move to next open
> > window.
> 
> Experiencing the same bug as Paul Oranje. Should we open a separate bug for
> this issue? (since *this* is a 'META' bug?)

Yes, this is a META,  and as can be seen on the tree list of "Depends on:" here the issue is already reported as bug 114858 (and its duplicates).

It has been corrected for the 6.0.3 and 6.1 releases, and likely just requires a user profile reset after upgrade install.