Created attachment 146304 [details] Global Menu - leaking ampersands SUMMARY I'd like to ask opinions on temporary disabling key accelerators (also known as &mnemonics) in the Global Menu applet. There several reasons to consider them being not production grade: - They don't respect theme setting for actually showing them or not. + https://bugs.kde.org/show_bug.cgi?id=389118 + https://bugs.kde.org/show_bug.cgi?id=249787 + https://bugs.kde.org/show_bug.cgi?id=155791 - Internationalization support is broken. For Cyrillic (ru_RU) it works (successfully triggers where it shows underlines) about one time out of 8. - They often leak those utility &ersands into visible text. - AFAICT sometimes ampersands are put before letters that are already taken — that would lead to duplicate accelerators, and is likely one of the reason why ampersands leak into UI. - Even successfully shown underlines in correct position without any visible ampersands — they often change text width, and thus the whole applet "jumps", extends and shrinks all the time if you press Alt repeatedly. This has something to do with ligatures and how <u> tag breaks them in rich text formatting. - They are heavily inconsistent. For example, a «Tools» menu may be assigned letter «T» in Dolphin (which also breaks «tee-o» ligature) but then a lowercase «L» in KMail; and after few Alt+Tabs back and forth they may even swap between apps! Isn't the whole point of accelerators to, well, accelerate your job by memorizing the keys? What can you memorize if they are constantly changing? - There's a good alternative to accelerators on top level menu: set a shortcut on a Global Menu applet instance. Pros: + At top level the count of menus is usually not that big that it can't be navigated with arrows keys. + It has the added benefit of single consistent shortcut to open/focus a menu. Cons: + Keyboard navigation could be better. Global shortcut should force focus on an applet, but don't open/expand the first item (like, usually, «File»). Instead it should merely highlight the first item and let you either open it with Down, Enter or Spacebar; or navigate to top-level siblings with Left/Right arrows or — it's important part — type in first letters of destination (like ComboBox supports). Opinions, please? STEPS TO REPRODUCE 1. Add «Global Menu» applet onto a panel if you don't have one already. 2. Open various pieces of software that have menus (KDE apps are usually good at it). 3. Press Alt repeatedly while switching the apps back and forth 4. Try launching apps in different locales, e.g. `LANGUAGE=ru_RU:ru LANG=ru_RU LC_ALL=ru_RU.UTF-8` SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.80 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.5-arch1-1 (64-bit) Graphics Platform: X11 plasma-desktop: 4edfcf42dd6a6ad04ecfc4f30236dd2ad80bd632 plasma-workspace: 2141988c3be9c5ea6d82530baa1d81c6a9dd110c plasma-framework: 346e0d8a0cac969bb8139129be05f48b6b40fc3a
Created attachment 146305 [details] Global Menu - inconsistent accelerators
Created attachment 146306 [details] Global Menu - Cyrrilic accelerators
Created attachment 146322 [details] Global Menu - Accelerators and System Settings This video shows inconsistent and conflicting accelerator keys that never work predictable. They are also randomly change on the fly and stop working whatsoever.
We (ratijas, David Redondo, Herzenschein and me) have talked about this a bit in the chat. I'll try to summarise for other people stumbling into this bug report (but without any promises of completeness): Most people were in favour of keeping these kinds of accelerators enabled. Instead the bugs being reported here should be fixed. "let's fix things instead of removing them" One important aspect that was brought up is that these accelerators are an accessibility feature: "Because of it being an accessibility feature. Even microsoft has guidelines that are explicit about using accelerators: https://docs.microsoft.com/en-us/windows/apps/design/accessibility/accessibility-checklist" It was also noted that there seem to be more problems concerning this with QML-based KCMs than QWidget-based ones. Overall I would suggest to split the problems being listed here into separate bug reports that can be acted upon. As far as I can tell we don't and won't want to disable accelerators in the Global Menu applet.
Sounds like a plan. :)
Yeah, thanks for the #sumup. So, as I stated in the chat, I don't really see how such broken and random thing could help anyone with accessibility, besides looking jerky, and why would a single global shortcut not solve all those problems. I acknowledge that there are some people who like and use accelerators feature a lot, and we should keep it for them (even if in a half-working state). Personally I am not a fan nor even a user, so I'd probably only care as much as to make Global Menu applet honor my "Always Hide" preference for keyboard accelerators. Sad to say it, but sounds like "patches are welcome". Otherwise, if no one steps up, it'd be more like #resolved #unmaintained.
I agree that the workflow you are recommending of pressing a set global shortcut to put focus onto the global menu bar is probably faster in a lot of cases than pressing Alt and then figuring out which additional key to press. The main advantage of accelerators IMO is that a user doesn't need to learn much to use them. They only need to be aware that pressing Alt shows them letters that directly activate an action. For the workflow you are recommending it is necessary for a user to configure/memorise a keyboard shortcut and get used to it. Users might never do this. It is also not a very scalable solution because they would need to learn a keyboard shortcut for every control element they might be interested in jumping to. Just pressing Alt on the other hand is something that can be learnt pretty much instantly. It might not be the fastest way to do it but maybe the user doesn't use the menu bar that much anyway that they would want to learn something extra to improve they speed. That's at least how I look at it. >Personally I am not a fan nor even a user, so I'd probably only >care as much as to make Global Menu applet honor my >"Always Hide" preference for keyboard accelerators. That's fine. You don't need to feel responsible for this. There is so much stuff that could be improved. From what I can tell this seems like a really pressing issue to you currently but it isn't as broken on my setup as it seems to be on yours. To me, it doesn't seem like something that needs immediate attention. >Sad to say it, but sounds like "patches are welcome". >Otherwise, if no one steps up, it'd be more like #resolved #unmaintained. Yes, that's fair. We can't always fix all bugs right away. If something is really annoying to a lot of people it normally doesn't take that long for someone to try and fix it. I haven't seen a whole lot of complaining about this so far but that might be because many of our applications don't really play well with keyboard-only usage currently.
> For the workflow you are recommending it is necessary for a user to configure/memorise a keyboard shortcut and get used to it. Users might never do this. Menu bar is so special that one prominent operating system has been shipping it as a dedicated panel on top of the screen for decades now. That same operating system doesn't assume or allow users making some weird multi-panel multi-applet setups, so it can afford shipping default shortcuts as well: for Dock, Menu and System tray — and I never heard anyone complaining about that (except maybe for the lack of Meta+1/2/3… shortcuts for apps in dock like Windows and Plasma does; but that's a different story). > It is also not a very scalable solution because they would need to learn a keyboard shortcut for every control element they might be interested in jumping to. Just pressing Alt on the other hand is something that can be learnt pretty much instantly. It might not be the fastest way to do it but maybe the user doesn't use the menu bar that much anyway that they would want to learn something extra to improve they speed. Come on, I never meant that users should set a shortcut per each control. See my previous paragraph about how menu bar is special. More generally, tools nowadays more often tend to be using the "command palette" approach: something like KRunner with a search bar and a list of results, which is as great for discoverability and productivity as classic menus won't ever get. (by the way, where's a special Help menu with a search field in this Global Menu applet?)
A possibly relevant merge request was started @ https://invent.kde.org/plasma/breeze/-/merge_requests/179
A possibly relevant merge request was started @ https://invent.kde.org/plasma/oxygen/-/merge_requests/17
Git commit 6e05c4441557e989273429ad4a5512d70124f657 by ivan tkachenko. Committed on 06/02/2022 at 20:15. Pushed by ratijas into branch 'master'. kstyle: Clarify options of mnemonics/accelerators Parity patch for oxygen theme: https://invent.kde.org/plasma/oxygen/-/merge_requests/17 M +3 -3 kstyle/config/ui/breezestyleconfig.ui https://invent.kde.org/plasma/breeze/commit/6e05c4441557e989273429ad4a5512d70124f657
Git commit 4325317fb341afb4c1744981a682f0ab9872b9dd by ivan tkachenko. Committed on 06/02/2022 at 20:12. Pushed by ratijas into branch 'master'. kstyle: Clarify options of mnemonics/accelerators Parity patch for breeze theme: https://invent.kde.org/plasma/breeze/-/merge_requests/179 M +3 -3 kstyle/config/ui/oxygenstyleconfig.ui https://invent.kde.org/plasma/oxygen/commit/4325317fb341afb4c1744981a682f0ab9872b9dd
>Menu bar is so special that one prominent operating system has been […] Now I see where you are coming from. I haven't used the Apple stuff a lot so I wasn't aware which behaviours might be expected. >Come on, I never meant that users should set a shortcut per each control. >See my previous paragraph about how menu bar is special. I am talking from the perspective that many users don't even know the shortcuts for copy and paste. I don't think what you are suggesting is too much to ask for any somewhat advanced computer user but for the noobs out there figuring out to press Alt when they want to activate something with the keyboard might already be difficult enough. Not saying that the workflow you are suggesting won't work. On the contrary I think that anyone that wants to have a mostly keyboard-driven workflow is probably quite eager to learn the necessary shortcuts. The good thing is that we can allow to have both and the multitude of allowed methods makes it more likely that users will be able to achieve what they want one way or another. >More generally, tools nowadays more often tend to be using the "command palette" approach: >something like KRunner with a search bar and a list of results, which is as great for discoverability >and productivity as classic menus won't ever get. > >(by the way, where's a special Help menu with a search field in this Global Menu applet?) It should be available on Wayland. Aside from that we should try to have this as a general functionality anyway: https://bugs.kde.org/show_bug.cgi?id=442099 There is also a bug report about combining KRunner and KCommandBar: https://bugs.kde.org/show_bug.cgi?id=437509