| Summary: | Correct the list of disabled shortcut keys per OS | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Yousuf Philips (jay) (retired) <philipz85> |
| Component: | LibreOffice | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | ||
| Severity: | enhancement | CC: | cno, erack, heiko.tietze, rb.henschel, vsfoote |
| Priority: | medium | ||
| Version: | 5.2.0.0.alpha0+ | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 98259 | ||
|
Description
Yousuf Philips (jay) (retired)
2016-03-03 06:53:20 UTC
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. |