Summary: | F10 as menu shortcut steals it from applications | ||
---|---|---|---|
Product: | [Applications] konsole | Reporter: | András Manţia <amantia> |
Component: | keyboard | Assignee: | Konsole Developer <konsole-devel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander.stehlik, auxsvr, christoph, evorster, felixernst, goo, kde, kdelibs-bugs, knezivan.au, nate, spiked.yar |
Priority: | NOR | ||
Version: | 24.02.0 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/utilities/konsole/-/commit/f982b54d723e3c69909ac343510dd62f188f2199 | Version Fixed In: | |
Sentry Crash Report: | |||
Attachments: |
This patch works for me
attachment-3191132-0.html |
Description
András Manţia
2024-03-01 13:12:32 UTC
Can confirm. But I'm not sure how much we can do about this, though. F10 is pretty standard for opening the menu. Maybe you should just un-bind it for yourself if you use apps that also want to use that shortcut? I wonder if Konsole could detect if a terminal application reacts to F10 or not and only open the menu when it doesn't. I don't know enough about Konsole to know if that is possible. On the flip side this would mean that any user that is accustomed to F10 to open menu might be surprised that this doesn't work if a certain terminal application is running. However, I think that would be less important than making sure the terminal application works as expected. In my opinion Konsole is special and should be conservative in what shortcuts it steals from the applications running in the terminal. I am not sure "being conservative" works here. When a completely blind person sits in front of Konsole and tries to go to the menu F10 is their only option AFAIK. Take that away and they can't even open the help menu AFAIK. That's why I suggested that Konsole should only give up control of the F10 key when the current terminal application uses it. This way the general accessibility of Konsole doesn't have to suffer just because some terminal applications also want to use F10. This bug is even more annoying than I thought: the shortcut keeps resetting itself to F10 from time to time (I don't know yet when it happens) despite changing it to "None". Configure Keyboard Shortucts Dialog also shown the Open Menu entry twice. (In reply to Felix Ernst from comment #4) > I am not sure "being conservative" works here. When a completely blind > person sits in front of Konsole and tries to go to the menu F10 is their > only option AFAIK. Take that away and they can't even open the help menu > AFAIK. > > That's why I suggested that Konsole should only give up control of the F10 > key when the current terminal application uses it. This way the general > accessibility of Konsole doesn't have to suffer just because some terminal > applications also want to use F10. I disagree. F10 is often used in terminal applications. People are used to Ctrl+C and Ctrl+V and other common shortcuts, but that's not how it works in Konsole. The same should be applied to F10 and F11. I'm pretty much blind and when I'm using terminal apps like I'm used to instead of getting F10 action from my application I'm getting some useless menu. In my opinion this is serious bug (In reply to András Manţia from comment #5) > This bug is even more annoying than I thought: the shortcut keeps resetting > itself That would be annoying but it would be considered unrelated to this bug. (In reply to Ivan from comment #6) > (In reply to Felix Ernst from comment #4) > > I am not sure "being conservative" works here. When a completely blind > > person sits in front of Konsole and tries to go to the menu F10 is their > > only option AFAIK. Take that away and they can't even open the help menu > > AFAIK. > > > > That's why I suggested that Konsole should only give up control of the F10 > > key when the current terminal application uses it. This way the general > > accessibility of Konsole doesn't have to suffer just because some terminal > > applications also want to use F10. > > I disagree. F10 is often used in terminal applications. People are used to > Ctrl+C and Ctrl+V and other common shortcuts, but that's not how it works in > Konsole. The same should be applied to F10 and F11. > > I'm pretty much blind and when I'm using terminal apps like I'm used to > instead of getting F10 action from my application I'm getting some useless > menu. > > In my opinion this is serious bug Of course any change we ever make (even if it is during a major transition from Qt 5 to Qt 6 like this) will go against previously expected behaviour. I don't really see though in what way what you are saying disagrees with me. I do agree with your point that it is unwanted when a terminal program's F10 shortcut doesn't work because it was stolen by Konsole. But this doesn't change the argument I made which was: "When a completely blind person sits in front of Konsole and tries to go to the menu F10 is their only option AFAIK. Take that away and they can't even open the help menu AFAIK."
> Of course any change we ever make (even if it is during a major transition
> from Qt 5 to Qt 6 like this) will go against previously expected behaviour.
> I don't really see though in what way what you are saying disagrees with me.
> I do agree with your point that it is unwanted when a terminal program's F10
> shortcut doesn't work because it was stolen by Konsole. But this doesn't
> change the argument I made which was: "When a completely blind person sits
> in front of Konsole and tries to go to the menu F10 is their only option
> AFAIK. Take that away and they can't even open the help menu AFAIK."
I disagree that conservative approach is not a way to go. Terminal is very special application and it should be excluded from a "normal" behaviour. IMHO F10 to open a menu is a stupid idea in the first place in the same way as F11 for full screen etc. It may work well in a browser, but not in all applications. And when it comes to terminal - it's not just an app, it's a container for running apps. I don't think that terminal should be aware what keys are used in a terminal app and to decide when to open the menu or to pass. I have lots of scripts I created that utilise all F keys. And I always loved Konsole. Suddenly I'm in a big trouble. Not to mention popular apps like mc, htop etc.
IMHO getting rid of this "feature" is a way to go, or at least adding something like shift+F10, like they did for copy-paste (ctrl+shift+c). I wouldn't be surprised if someone wants to use ctrl+c in terminal for copy :)
Shift+F10 in Konsole would make sense to me, and match how other common shortcuts are handled in terminal apps to avoid conflicting with CLI software. Yes, Shift+F10 could work. This way there would still be some keyboard-only way to go to the menu. It's also a common enough change from the typical shortcuts that a user might be able to guess it. I'll move this bug report from frameworks to Konsole because the keyboard shortcut should be changed for Konsole and not in frameworks. *** Bug 477330 has been marked as a duplicate of this bug. *** My opinion here is that a lot of the terminal applications predate the Konsole by decades, and the key bindings of these programs should be respected, and not interfered with. Mindnight Commander is a fine example. At the very least, some mechanism should be provided to disable Qt's shortcut keys on Konsole, or provide a way of changing the default console program in KDE to something that does not highjack the function keys from the program running in the console. For the record you may want to use Esc+0 instead of F10 until Shift+F10 is set as default for Konsole (hope that this change will be shipped in 24.08) Esc+0 is actually used in well-known cli apps like mc or htop and maybe others as a replacement for F10. (In reply to Felix Ernst from comment #11) > I'll move this bug report from frameworks to Konsole because the keyboard > shortcut should be changed for Konsole and not in frameworks. This issue connected with "KHamburgerMenu". F10 open menu only with ctrl+shift after removing "burger" from MainWindow. Looks like a framework issue. May be KStandardAction::hamburgerMenu() adds implicit F10 shortcut. Created attachment 173249 [details]
This patch works for me
If you can't wait for merge ;)
A possibly relevant merge request was started @ https://invent.kde.org/utilities/konsole/-/merge_requests/1027 Created attachment 173381 [details] attachment-3191132-0.html Ctrl+Shift+F10 already brings up the menu in konsole, since https://invent.kde.org/utilities/konsole/-/commit/6e12d788642816fd892dc7bbe5ed99d0a95a704b (In reply to ninjalj from comment #18) > Ctrl+Shift+F10 already brings up the menu in konsole, since > https://invent.kde.org/utilities/konsole/-/commit/6e12d788642816fd892dc7bbe5ed99d0a95a704b Yep. With proposed pull request: 1. Single F10 key will always delivered to the console application. 2. Ctrl + Shift + F10 will activate menu and enable it if hidden. PR does not change this behavior. 3. Shift + F10 to activate menu or to show burger menu if main menu is hidden. Git commit f982b54d723e3c69909ac343510dd62f188f2199 by Kurt Hindenburg, on behalf of Michael Labiuk. Committed on 27/09/2024 at 20:52. Pushed by hindenburg into branch 'master'. shortcuts: do not grab F10 key F10 is a standard shortcut to open menu but it cannot be used in a terminal because many console applications are using it too. Updating burger menu shortcut: F10 -> Shift+F10 Also move burgermenu initialization after main window. It is needed to call correctStandardShortcuts() once. M +12 -6 src/MainWindow.cpp https://invent.kde.org/utilities/konsole/-/commit/f982b54d723e3c69909ac343510dd62f188f2199 |