Description: As LibreOffice writer has evolved over the years, many keyboard key combinations have been silently "removed" from the list of ones whose action can be customized by the user. This has led to such bugs as 49091, 53190, 93402, 146174 as well as this old one that I filed in 2010: https://bz.apache.org/ooo/show_bug.cgi?id=113502. Since LO developers don't seem inclined to address these bugs, I decided to try to fix them myself. Attached is a patch that addresses the bugs and introduces an optional capability of displaying how keystrokes are processed. Bug 146174 was introduced in commit https://gerrit.libreoffice.org/c/core/+/122926 which attempted to resolve bug 144846. My patch bypasses the code (but does not remove it), thereby reintroducing bug 144846. I am hoping that another way of resolving that bug can be developed that does not remove the ability to customize the alt+letter keystrokes that would otherwise be processed as menu-access mnemonics. In addition to proposing a resolution to the aforementioned bugs, I am hoping that this issue will lead to discussion of how to better manage and document which keys trigger which functions and how, including documenting for each key combination: (1) Where the default actions are implemented: menu access hotkey versus uno function bound via keyboard customization versus managed within key input routines in LO code. (2) Determining whether or not the key can be reassigned by users via keyboard customization. For instance, it is not possible to customize Shift+Control+0 but there doesn't seem to be a good reason for that. On the other hand, it is possible for a user to change the function of the unshifted arrow keys and that seems like a recipe for disaster. Had there been a common resource for developers to consult, then maybe bug 144846 could have been avoided when assigning menu item mnemonics to the Impress Properties menu. Steps to Reproduce: Use keyboard customization function to 1.Assign MyFavoriteFunction1 to Alt+Right 2.Assign MyFavoriteFunction2 to Alt+A Actual Results: 1. Alt+Right resizes expands column when in table and nothing otherwise 2. Alt+A brings up Table submenu Expected Results: 1. Alt+Right should trigger MyFavoriteFunction1 2. Alt+A should trigger MyFavoriteFunction2 Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: See referenced bug reports. Picture of "Help - About Libreoffice" will be attached. But many of the bugs have been around since OOO 3.2.
Created attachment 179196 [details] Help - About
Created attachment 179197 [details] Tested fix
Thanks for the patch, not sure it is really of any help as it is gtk3 only and applies just to writer. More general structure for mix of core short-cut binding, short-cuts assigned to UNO controls, and mnemonic 'accelerators' assigned dynamically or by l10n to the various UI controls--and the user 'customization' available to each category does need review and alignment.
(In reply to V Stuart Foote from comment #3) > Thanks for the patch, not sure it is really of any help as it is gtk3 only Only one part of the patch is gtk3 and I honestly do not expect that to be accepted as is. I am hoping that this leads to another solution to bug 144846 that doesn't remove ability to customize alt+letter keystrokes when vtk == gtk. > and applies just to writer. The other part of the patch does apply only to writer table sizing keystrokes since that is the source of the older bug reports. I am sure that there are other cases within writer and the other modules wherein keystrokes are processed and consumed without considering that they may have been customized. > More general structure for mix of core short-cut > binding, short-cuts assigned to UNO controls, and mnemonic 'accelerators' > assigned dynamically or by l10n to the various UI controls--and the user > 'customization' available to each category does need review and alignment. Absolutely! I would hope that outcome of such a review would still leave users the ability to customize the behaviour of as wide a range of keystrokes as possible while at the same time "protecting" them from doing stupid or insane things ... like remapping the arrow keys:)
We have plenty of tickets around keyboard customization, see bug 41560 about the customization and bug 107243 locale issues. The request here is rather about mnemonics (alt+accelerator, bug 146174), which is different to what is assigned to UNO commands. Some of the shortcuts are hard-coded. For example pressing return adds a paragraph break, arrow down / page down scrolls by a certain amount of lines etc. Some of these hard-wired shortcuts lead to the fact that you cannot customize this shortcut. An example is KEY_F1 and .uno:HelpIndex - F1 is blocked, perhaps because it's used in debug scenarios. Or for other reasons, see comment at MenuBarManager::FillMenuManager(). The point is that blocking shortcuts for some reasons affects usability. We should eliminate that one by one. And my personal pet in this regard, bug 115052, should improve the UI anyway. Back to the question... there is none. Suggest to resolve this ticket as INVALID. Or have I missed the point?
(In reply to Heiko Tietze from comment #5) > We have plenty of tickets around keyboard customization, see bug 41560 about > the customization and bug 107243 locale issues. The request here is rather > about mnemonics (alt+accelerator, bug 146174), which is different to what is > assigned to UNO commands. This bug and the bugs I mentioned (bug 49091, bug 53190, bug 93402, bug 146174) should be added to meta bug 41560. The request here is NOT simply about mnemonics but about the ability to override those mnemonics via keyboard customization. We have been able to do this for years until https://gerrit.libreoffice.org/c/core/+/122926. Part of my patch addresses that in a rather unsubtle way, so I do not expect that part to be accepted as is. The request is also about reinstating a whole range of keystrokes for customization that were pre-emptively removed many years ago for interactive table sizing functions. The other part of my patch fixes that, while providing a method to regain access to those functions even when the keystrokes are reassigned. > Some of the shortcuts are hard-coded. For example pressing return adds a > paragraph break, arrow down / page down scrolls by a certain amount of lines > etc. Some of these hard-wired shortcuts lead to the fact that you cannot > customize this shortcut. An example is KEY_F1 and .uno:HelpIndex - F1 is > blocked, perhaps because it's used in debug scenarios. Or for other reasons, > see comment at MenuBarManager::FillMenuManager(). Return, Arrow Down, and Page Down all appear to be customizable. While customization of Return is ignored, it is successful for the other keystrokes. The keystrokes that are listed in the customization dialog but are greyed out are are the ones reserved by vcl (see ReservedKeys in vcl/source/app/svapp.cxx). While I have been able to see how vcl uses most of the keys listed, I cannot figure out why vcl reserves Shift+Control+[0-9]. > The point is that blocking shortcuts for some reasons affects usability. We > should eliminate that one by one. And my personal pet in this regard, bug > 115052, should improve the UI anyway. Interesting bug. It all boils down to scan codes and how to best to give them a symbolic name. > Back to the question... there is none. Suggest to resolve this ticket as > INVALID. Or have I missed the point? You can deduce that I completely disagree :)
(In reply to Vince from comment #6) > The request here is NOT simply about mnemonics but about the ability to > override those mnemonics via keyboard customization. The customization changes the assignment of shortcuts to UNO commands. It never changed mnemonics from _File (alt+F) to F_ile (alt+I). You may have Alt+P for Open, instead of ctrl+O, but the mnemonic alt+O will work anyway. Alt+<key> combinations should not be used for shortcuts at all.
(In reply to Heiko Tietze from comment #7) > (In reply to Vince from comment #6) > > The request here is NOT simply about mnemonics but about the ability to > > override those mnemonics via keyboard customization. > > The customization changes the assignment of shortcuts to UNO commands. It > never changed mnemonics from _File (alt+F) to F_ile (alt+I). You may have > Alt+P for Open, instead of ctrl+O, but the mnemonic alt+O will work anyway. Perhaps I didn't describe it precisely. With a fresh profile, Alt+a brings up the table submenu. Since I don't need to access the table submenu very often, I prefer for that keystroke to do something more useful to me: execute my MyFavoriteMacro. I customize the keyboard to assign Alt+a to do just that. When I need to access the table submenu, I can still do so with a variety of other methods: mouse click; type F6 (focus on menubar), followed by 'a'; type F10, followed by right arrow 5 times. All of this worked just fine for many years but stopped working recently. > Alt+<key> combinations should not be used for shortcuts at all. Where does this come from? The capability was introduced a long time ago, after lots of impassioned discussion (see https://bz.apache.org/ooo/show_bug.cgi?id=4756). I suspect a lot of people are using it, including those who reported bug 146174.
(In reply to Vince from comment #8) > > Perhaps I didn't describe it precisely. With a fresh profile, Alt+a brings > up the table submenu. Since I don't need to access the table submenu very > often, I prefer for that keystroke to do something more useful to me: > execute my MyFavoriteMacro. I customize the keyboard to assign Alt+a to do > just that. For vcl backends other than gtk3 it still does. Only the gtk3/4 implementation has been affected. > > Alt+<key> combinations should not be used for shortcuts at all. > > Where does this come from? The capability was introduced a long time ago, > after lots of impassioned discussion (see > https://bz.apache.org/ooo/show_bug.cgi?id=4756). I suspect a lot of people > are using it, including those who reported bug 146174. <Alt>+<key> are still fully customizable, except the behavior difference in handling the accelerators vs. shortcuts got a major tweak for supporting gtk3 DE with the work on bug 92630, which now splits the accelerator key sequence. <Alt> is now the gtk3 compliant toggle to show the mnemonics assigned, the underlined character for the lable. So now <alt>, <f> in sequence will open the menu; <alt>+<f> will read the short-cut if assigned in the customize dialog, except on gtk3/4--check it out with the vcl 'gen', 'kf5', or on a Windows build. If you don't like that gtk3 compliance feature, don't use a gtk3 based DE.
(In reply to V Stuart Foote from comment #9) > (In reply to Vince from comment #8) > > > > > Perhaps I didn't describe it precisely. With a fresh profile, Alt+a brings > > up the table submenu. Since I don't need to access the table submenu very > > often, I prefer for that keystroke to do something more useful to me: > > execute my MyFavoriteMacro. I customize the keyboard to assign Alt+a to do > > just that. > > For vcl backends other than gtk3 it still does. Only the gtk3/4 > implementation has been affected. > > > > > Alt+<key> combinations should not be used for shortcuts at all. > > > > Where does this come from? The capability was introduced a long time ago, > > after lots of impassioned discussion (see > > https://bz.apache.org/ooo/show_bug.cgi?id=4756). I suspect a lot of people > > are using it, including those who reported bug 146174. > > <Alt>+<key> are still fully customizable, except the behavior difference in > handling the accelerators vs. shortcuts got a major tweak for supporting > gtk3 DE with the work on bug 92630, which now splits the accelerator key > sequence. > > <Alt> is now the gtk3 compliant toggle to show the mnemonics assigned, the > underlined character for the lable. > > So now <alt>, <f> in sequence will open the menu; <alt>+<f> will read the > short-cut if assigned in the customize dialog, except on gtk3/4--check it > out with the vcl 'gen', 'kf5', or on a Windows build. > > If you don't like that gtk3 compliance feature, don't use a gtk3 based DE. The gtk3 compliance feature never presented issues. Nothing broke after bug 92630 was resolved. Bug 146174 surfaced after the commit last October which ironically addressed what appears to be a bug in the way gtk3 processes mnemonics (https://bugs.documentfoundation.org/show_bug.cgi?id=144846#c5). The discussion in this thread seems to be focussed around my proposed changes to vcl/unx/gtk3/gtkframe.cxx. I realize that I need to do something better than bypassing the recently introduced code, so I am going to propose a more constructive patch.
Created attachment 179264 [details] Updated patch
This revised patch contains the following changes: vcl/unx/gtk3/gtkframe.cxx Instead of bypassing the code, I moved it to another location in the code. Based on my admittedly short testing, this fixes bug 146174 AND preserves fix to bug 144846. sw/source/uibase/docvw/edtwin.cxx No changes. The proposed changes to these modules are intended as an attempt to address "Regaining user control over keyboard customization". If desired, I can break this into 2 patches and post them to their respective bug reports.
(In reply to Vince from comment #8) > .... Alt+a brings up the table submenu. Since I don't need to access > the table submenu very often, I prefer for that keystroke to do something > more useful to me: execute my MyFavoriteMacro. I customize the keyboard to > assign Alt+a to do just that. Okay, accepted. > > Alt+<key> combinations should not be used for shortcuts at all. > Where does this come from? The capability was introduced a long time ago... Not by default, at least. The A in T_able will still be underlined as a clue for the mnemonic. And dialogs also provide this access. For experts who know the consequences of their doing, the Alt combinations are okay, of course. (In reply to Vince from comment #11) > Created attachment 179264 [details] > Updated patch If you are happy with your patch, how about submitting to Gerrit so we can involve the experts? https://wiki.documentfoundation.org/Development/gerrit
*** Bug 146174 has been marked as a duplicate of this bug. ***
(In reply to Vince from comment #12) > "If desired, I can > break this into 2 patches and post them to their respective bug reports. I can take care of splitting it and submitting to gerrit if you would like to provide a license statement like https://wiki.documentfoundation.org/Development/Developers#License_Statements
(In reply to Caolán McNamara from comment #15) > (In reply to Vince from comment #12) > > "If desired, I can > > break this into 2 patches and post them to their respective bug reports. > > I can take care of splitting it and submitting to gerrit if you would like > to provide a license statement like > https://wiki.documentfoundation.org/Development/Developers#License_Statements Thanks, Caolán All of my past & future contributions to LibreOffice may be licensed under the MPLv2/LGPLv3+ dual license. I noticed that this bug is now entirely focused on the gtk3 vcl part of my patch. There is another part to my patch that involves writer keyboard handling. Should I split that off and add it to the appropriate (really old) bug reports?
(In reply to Heiko Tietze from comment #13) > (In reply to Vince from comment #8) > If you are happy with your patch, how about submitting to Gerrit so we can > involve the experts? https://wiki.documentfoundation.org/Development/gerrit Thank you for this very constructive suggestion, I will look into that. I have been using SO/OOO/LO for a long time but it was my frustration with thwarted keyboard customization over the years that finally drove me to undertake the mind-boggling task of understanding and changing the relevant code. I figured that offering a proposed fix would be more effective than simply complaining in a bug report. If it is better to propose patches on Gerrit rather than adding them as an attachments to bug reports, then I will do so. I am confident enough in my latest patch that I plan on rebuilding my current 7.2.4.1 LO with it applied.
(In reply to Vince from comment #16) > I noticed that this bug is now entirely focused on the gtk3 vcl part of my > patch. There is another part to my patch that involves writer keyboard > handling. Should I split that off and add it to the appropriate (really old) > bug reports? What I would do is two patches (two submissions to gerrit), the gtk-specific one with a commit message mentioning tdf#148258 (which will cause it to get auto-mentioned here when pushed) and the other with a commit message mentioning the other bug number. Feel free to add me as a reviewer in the gerrit ui for them.
(In reply to Vince from comment #17) > If it is better to propose patches on Gerrit rather than adding them as an > attachments to bug reports, then I will do so. Do both :-). BZ is good for discussion and transparency while patches are the way to communicate with developers. I'd be glad if the whole keyboard implementation becomes revamped. These KEY_* hard-coded variables limit us to ASCII, the hard-coded associations between codes and key strokes should be removed, and the customization UI needs some love too. You are very welcome to work on this topic!
My original purpose in creating this bug was to make a plea to LO developers to be careful about honoring user keyboard customization when making changes. I also offered a patch that addressed 2 bugs that aggravated me in particular: the older bug 49091 (and its many duplicates) and the relatively recent bug 146174. I have split my patch into 2: one which affects Writer-specific keyboard handling and the other which affects VCL-gtk3. The VCL-gtk3 was reviewed and accepted (thanks Caolán McNamara) -- see messages in bug 146174. I will be submitting the Writer-specific patch today and further discussion of that it be moved to bug 49091. Since most of the discussion here revolved around VCL-gtk3, I am going to close this bug as a duplicate of 146174. *** This bug has been marked as a duplicate of bug 146174 ***