When my question regarding why various shortcut keys were disabled in the keyboard shortcuts customization dialog was forwarded to the developers mailing list and i received replies from both Regina and Eike that some were disabled due to accessibility and others were disabled due to Calc's default functions (weird that disablement only happens on linux), i went through the HIGs for Windows, Mac and Linux and concluded that most of these restrictions should be removed and another set of restrictions need to be added per OS. Only if the OS itself is blocking the use of a shortcut key, should LO not allow a user to assign that shortcut key, else if a user wishes to change the key, there shouldnt be any restrictions on it. These are the commands that should likely be retained and we could make it cross platform. Alt + F4 - reserved on Windows Ctrl + Alt + F4 - reserved on Linux We could expand on these and based on HIG recommendations restrain users for very important shortcuts like these. Help - F1: Windows & Linux, Cmd + Shift + ?: Mac Context Menu - Shift + F10: Windows & Linux (reserved on Mac) All the research was can be found in this google doc. https://docs.google.com/document/d/1Aek0chOK2h3bBUe1J0bObjbTSOgau_HMeMJ5ws-dM58/edit?usp=sharing The LO code that does this restriction is here. http://opengrok.libreoffice.org/xref/core/vcl/source/app/svapp.cxx#108 So step 1 would be to trim down the existing list and step 2 would be to add entries not presently found in the list that should likely be disabled based on each OS's HIG.
Before we make any move in this direction, we have to pin down why in the various OS the current reserved vcl shortcut keys as defined [1][2] are not being honored across the UI in each OS. And then correct what has gone wonky in handling the vcl reserved with conflicting .xcu and gtk3 work. So, yes clean them up in accordance with more recent HIG per OS, but we need to then honor the reserved status and continue to exclude what remains for our functional needs from user customization. Believe that really needs to remain the case whether OS HIG reserved or not. With all that sorted only the remaining non-reserved should be available for user customization and i18n support [3] as global and per module XCU assignments. =-ref-= [1] core global Short-cut assignments made in vcl -- http://opengrok.libreoffice.org/xref/core/vcl/source/window/keycod.cxx#29 [2] http://opengrok.libreoffice.org/xref/core/vcl/source/app/svapp.cxx#88 [3] http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/Accelerators.xcu
(In reply to V Stuart Foote from comment #1) > Before we make any move in this direction, we have to pin down why in the > various OS the current reserved vcl shortcut keys as defined [1][2] are not > being honored across the UI in each OS. And then correct what has gone > wonky in handling the vcl reserved with conflicting .xcu and gtk3 work. The reserved shortcut keys are being honored on Windows, Linux, and Mac, though on Mac, their HIG has suggested alternative shortcut keys for some of them. > So, yes clean them up in accordance with more recent HIG per OS, but we need > to then honor the reserved status and continue to exclude what remains for > our functional needs from user customization. Believe that really needs to > remain the case whether OS HIG reserved or not. HIGs have an OS-level reserved list and an App-level recommended list of shortcut keys. From our current list of reserved shortcuts, only two are found on the OS-level - Alt + F4 (Windows), Ctrl + Alt + F4 (Linux). So if a user wants to reassign an App-level shortcut that we currently have on our reserved list, like Shift + F2, we shouldnt stop them from doing so.
(In reply to Yousuf (Jay) Philips from comment #2) > The reserved shortcut keys are being honored on Windows, Linux, and Mac, > though on Mac, their HIG has suggested alternative shortcut keys for some of > them. > Nope they are not. Some mix of the vcl defined (keycod.cxx) and reserved (svapp.cxx) short-cuts do not function correctly inside the modules, nor the StartCenter and especially troublesome not from the main menu. For example: bug 92516 - Q_MOD1, (and the X_MOD2 accelerator) bug 92866 - Q_MOD1 bug 97511 - Q_MOD1 bug 95410 - S_MOD1 IMHO it would be ill advised to go changing things until it can be determined where and why vcl and the key handling mechanisms have diverged, and get that all back under control. Once that is stable--adjusting to the OS HIG would make sense, but not before.
(In reply to V Stuart Foote from comment #3) > Nope they are not. Some mix of the vcl defined (keycod.cxx) and reserved > (svapp.cxx) short-cuts do not function correctly inside the modules, nor the > StartCenter and especially troublesome not from the main menu. > > For example: > > bug 92516 - Q_MOD1, (and the X_MOD2 accelerator) > bug 92866 - Q_MOD1 > bug 97511 - Q_MOD1 > bug 95410 - S_MOD1 None of those are reserved keys in LibreOffice, those are assigned keys. I can go into the keyboard customization dialog and change Ctrl + Q or Ctrl + S.
(In reply to Yousuf (Jay) Philips from comment #4) > (In reply to V Stuart Foote from comment #3) > > Nope they are not. Some mix of the vcl defined (keycod.cxx) and reserved > > (svapp.cxx) short-cuts do not function correctly inside the modules, nor the > > StartCenter and especially troublesome not from the main menu. > > > > For example: > > > > bug 92516 - Q_MOD1, (and the X_MOD2 accelerator) > > bug 92866 - Q_MOD1 > > bug 97511 - Q_MOD1 > > bug 95410 - S_MOD1 > > None of those are reserved keys in LibreOffice, those are assigned keys. I > can go into the keyboard customization dialog and change Ctrl + Q or Ctrl + > S. Right, but the function of those core vcl assignments including handling the reserved keys are what has become unreliable. It seems they are being overridden by conflicting XCU assignments (l18n and "widget-du-jour") and as a result we now have incorrectly functioning menus, dialogs, and actions in modules throughout the UI. Believe that pretty much anywhere a short-cut key is not functioning correctly it is either because the assignment in vcl has been ignored or that assignment is no longer instrumented correctly to perform the intended action. What I'm asking for is to get a better handle on why. And then as the OS reserved actions are reworked and included to vcl, to make sure they get handled correctly elsewhere.
(In reply to V Stuart Foote from comment #5) > Right, but the function of those core vcl assignments including handling the > reserved keys are what has become unreliable. It seems they are being > overridden by conflicting XCU assignments (l18n and "widget-du-jour") and as > a result we now have incorrectly functioning menus, dialogs, and actions in > modules throughout the UI. That maybe true but thats not within the scope of this enhancement, which is about freeing up reserved keys, that all work fine presently.