Created attachment 123718 [details] Context menu click session. There are lot's of checkboxes and radiobuttons found in many context menus and submenus or subsubmenus of those menus. It is very cumbersome to configure many of them as everytime a checkbox or a radiobutton is selected, the whole context menu vanishes. For the second, third, etc. checkbox/radiobutton the whole process of right clicking, going through the menu/submenu and selecting/deselecting starts over and is not very efficient. I therefore propose to keep it the menu/submenus opened after a click on a radiobutton or checkbox and only close it if the user clicks somewhere outside of the context menu or presses ESC as the user would usually do if nothing was selected.
I would tend to agree. However this isn't something plasmashell controls. Maybe Breeze? Or maybe Qt? Or our QPA? David, do you know?
I'm not sure I agree, I fear it will seem random and whilst it might be more steps for this specific example, it increases the steps in all the situations where you do want to dismiss after checking something, resulting in a very minimal net gain. In any case, I checked Qt, it's all internal within QMenu. QMenuPrivate::activateAction closes the menu. Triggering an action is exactly the same path regardless of whether the action is checkable or not.
(In reply to David Edmundson from comment #2) > I'm not sure I agree, I fear it will seem random and whilst it might be more > steps for this specific example, it increases the steps in all the > situations where you do want to dismiss after checking something, resulting > in a very minimal net gain. > That's a counterargument. If it is implementable, would you both be fine with a magic key, like Ctrl or Shift, which, if pressed, will keep the context menu open? I don't think that this will hurt but gives us both advantages.
Thanks David. Since this is all in Qt, you'd need to go upstream anyway to ask them to either change this or make it configurable. There's nothing we can do until and unless that happens.
(In reply to Nate Graham from comment #4) > Thanks David. > > Since this is all in Qt, you'd need to go upstream anyway to ask them to > either change this or make it configurable. There's nothing we can do until > and unless that happens. Thanks, I will open a request upstream in that case.
> If it is implementable, would you both be fine with a magic key, like Ctrl or Shift, which, if pressed, will keep the context menu open? It sounds like the workflow where you'd only think "I should have pressed control" only after the menus has gone away. I genuinely can't see anyone using it.
(In reply to David Edmundson from comment #6) > > If it is implementable, would you both be fine with a magic key, like Ctrl or Shift, which, if pressed, will keep the context menu open? > > It sounds like the workflow where you'd only think "I should have pressed > control" only after the menus has gone away. With the time users will get accommodated to it and then probably find it very useful. However, I am open for better suggestions for a better UX. > I genuinely can't see anyone using it. Never say "not anyone". I'd be the counter proof. :-)
Try it: https://phabricator.kde.org/P489 on QtBase
Great, there's already a request pending for 10 years ... https://bugreports.qt.io/browse/QTBUG-6635 (In reply to David Edmundson from comment #8) > Try it: https://phabricator.kde.org/P489 on QtBase I will try to compile it later. Great, there's already a request pending for 10 years ... https://bugreports.qt.io/browse/QTBUG-6635