I find it somewhat sad that the change in comment #9 are implemented without checking how confusing it ends up working in the end. 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. 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'.Īs 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. This state is also not coupled with the two others. 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. ![]() One can make a LO window go full-screen using the green bubble on the title bar, or use View:Full Screen. Is the "full-screen" you talk about here LO's own such, or the OS X one? Note that sadly they are orthogonal. 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.Īs 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. 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. ![]() with all the video tutorials and such then being platform specific.Īs we had different shortcuts between Windows/Linux and Mac OS, just like we have menu bar differences (e.g. 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 link. 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. > This will be a documentation and UX nightmareĪs someone who works in documentation and UX, i dont see this as a nightmare. Find & Replace is Ctrl+H on Windows and Ctrl + R on KDE. 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. 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. F11 is assigned to the Styles & Formatting window/sidebar, but it is an OS reserved shortcut on Mac to show the desktop. 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. ![]() > Do we really want to divert our keymaps per platform? (In reply to Björn Michaelsen from comment #5)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |