| Summary: | Action shortcut default to "Alt+关" if not specified | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kirigami | Reporter: | Guo Yunhe <i> |
| Component: | general | Assignee: | Marco Martin <notmart> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | cody.hxlo, CoelacanthusHex, kde, nate, toda.ryunosuke |
| Priority: | NOR | ||
| Version: | 5.57.0 | ||
| Target Milestone: | Not decided | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=406035 https://bugs.kde.org/show_bug.cgi?id=420488 |
||
| Latest Commit: | Version Fixed In: | ||
| Attachments: |
Screenshot of Discover
Alt accelerators Better automatic allocation |
||
Created attachment 119950 [details]
Screenshot of Discover
This is the example in Discover left drawer.
See also Bug 406035. it's following the convention of qwidget applications. how does work with shortcuts on normal apps, like kate, dolphin and what not? in QWidgets apps, the alt accelerator is shown as a line under the appropriate character in the text, not as a tooltip that appears on hover. The same thing should happen here. (In reply to Nate Graham from comment #4) > in QWidgets apps, the alt accelerator is shown as a line under the > appropriate character in the text, not as a tooltip that appears on hover. > The same thing should happen here. it does? would be ok to restrict automatic shortcuts to standard latin? (then having to explicitly set one with a non latin string which can have a shortcut) Created attachment 122728 [details]
Alt accelerators
I'm talking about the Alt-key accelerators in QWidgets apps (see attachment). Are we talking about the same thing?
Qt Widgets applications must specify Alt-key accelerators with "&". For example: &Edit And it can be translated in non-Latin languages: 编辑(&E) But in Kirigami it just chooses the first character, no matter what it is. in kirigami & is supported as well. it also chooses the first available letter for those which don't have an &, which is the same thing happening in qwidget applications when are running under plasma *** Bug 417467 has been marked as a duplicate of this bug. *** Here are a lot of complains from users. When they see these weird shortcut tooltips, they first blame translation team but it is not something we can control. Here shouldn't be such a automatic shortcut generation. The tooltip should be used for more important information, not just for shortcut. It is against the knowledge we have for all Qt Widgets and QtQuick based applications. Shortcuts should only be enabled when the developer really mean to use it. And it should be visible for all translation teams. The old good & syntax is a solid solution that has been trusted for 25 years. Please just keep it and nothing else. *** Bug 420488 has been marked as a duplicate of this bug. *** (In reply to Marco Martin from comment #9) > it also chooses the first available letter for those which don't have an &, > which is the same thing happening in qwidget applications when are running > under plasma This does not work at all in some languages, this is basically what the bug report is about. (In reply to Marco Martin from comment #6) > would be ok to restrict automatic shortcuts to standard latin? (then having > to explicitly set one with a non latin string which can have a shortcut) Yes please. Also when if translators need to manually set an accelerator or shortcut key, please clearly mark that cases so translators can take care of that. Currently in QWidget application, no accelerator key will be assigned if the translated string contains no latin-1 character. This is also far from ideal. I also wrote a report about that too: https://marc.info/?l=kde-frameworks-devel&m=158782004706664&w=2 Created attachment 142393 [details]
Better automatic allocation
This problem is the same for Japanese. EXPECTED RESULT If shortcut property is not specified, it is to automatically assign the same characters as in the source text. As shown in the attached figure.(prev post) |
SUMMARY STEPS TO REPRODUCE 1. Have the following code: --------------------------------------------- import org.kde.kirigami 2.0 Action { id: aboutAction iconName: "help-feedback" text: i18n("About") } --------------------------------------------- 2. text is translated to "关于" in Chinese. 3. Mouse hover on the item, show a tooltip. OBSERVED RESULT The tooltip is "Alt+关", an invalid shortcut. Because you cannot find the key "关" in any keyboard. EXPECTED RESULT If shortcut property is not specified, it shouldn't generate a shortcut. We cannot make sure every action begins with unique letters or even valid letters. If developers defined action shortcut with same letter, conflicts will happen. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION