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
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
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.
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.
Ctrl + G as Find Next - https://gerrit.libreoffice.org/23407
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
(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
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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;)
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.
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.
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).
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.
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.
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?
See https://gerrit.libreoffice.org/#/c/48796/ . It would be great if somebody running OS X 10.9 or 10.10 could test this.
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).
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.
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.
(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?)
(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.