GNOME Bugzilla – Bug 688729
keep menu open when toggling switches
Last modified: 2021-07-05 14:19:25 UTC
This lets the user see what happens as a result (network connection status changes). This is also analogous to how we treat the combo box in the user menu and the slider in the sound menu
Created attachment 229476 [details] [review] popupMenu: Optionally leave menu open after enabling switch Switches in menus are used to (de)activate features or services. In the common case, the current behavior of closing the menu after activating the switch is fine, however in some cases the switch primarily affects the menu itself - one example being the wireless switch in the network menu, which results in the list of available WLANs being filled when enabled. In those cases it makes sense to leave the menu open, as it is very likely that the next action
Created attachment 229477 [details] [review] status: Do not close menu after activating some switches
I wrote those patches after seeing the downstream bug and forgot about them ...
Review of attachment 229476 [details] [review]: ::: js/ui/popupMenu.js @@ +801,3 @@ return; + if (this._closeMenuWhenEnabled || this._switch.state) this._switch.state is true if the switch went from false to true, so this seems backwards, ie. chaining up when enabling.
Review of attachment 229477 [details] [review]: Looks fine
*** Bug 690727 has been marked as a duplicate of this bug. ***
Review of attachment 229476 [details] [review]: "as it is very likely that the next action" Um? Also, why only close on enabled, rather than just keep it open always? Would make more sense to me that way.
Review of attachment 229477 [details] [review]: We should also add this for the Universal Access menu.
(In reply to comment #7) > Also, why only close on enabled, rather than just keep it open always? Would > make more sense to me that way. The idea is to only keep the menu open when toggling the switch results in new UI becoming visible in the popup itself, and otherwise stay consistent with GTK's check menu items. (In reply to comment #8) > We should also add this for the Universal Access menu. Not according to the rationale above, e.g. that proposal only makes sense to me if we change the general behavior (In reply to comment #4) > + if (this._closeMenuWhenEnabled || this._switch.state) > > this._switch.state is true if the switch went from false to true, so this seems > backwards, ie. chaining up when enabling. Right. I tested the patch with the bluetooth menu, which oddly enough requires to logic to be reversed. I'll look into it if we decide that we do want to change the switch behavior for selected items only.
(In reply to comment #9) > (In reply to comment #7) > > Also, why only close on enabled, rather than just keep it open always? Would > > make more sense to me that way. > > The idea is to only keep the menu open when toggling the switch results in new > UI becoming visible in the popup itself, and otherwise stay consistent with > GTK's check menu items. I've had several people come to me saying that when they tried out an option on menus, it "didn't work". The menu disappearing on click rather than showing the toggle was confusing (and also because the item they picked, "Large Text", didn't appear to do anything, because of some bug I imagine).
I think it makes sense to always keep the menu open for switches. Simple and understandable.
I also want to point out that I that I told both of them them that it worked just like a menu and it snapped in their head. They didn't see the status options at the top as behaving like menus, but "option panels", for whatever reason.
Created attachment 233226 [details] [review] popupMenu: Leave menu open after activating switch Switches in menus are used to (de)activate features or services. It is often of interest to users to be able to see the result of the operation, in particular when the menu itself changes (e.g. additional items being shown/hidden).
Review of attachment 233226 [details] [review]: Code is obviously correct, but it needs designer review of course.
Is this going to go in?
(In reply to comment #15) > Is this going to go in? Having run with that patch for a while, I've stumbled upon a couple of cases where leaving the popup open is just plain wrong. Examples include cases where activating the switch triggers a system modal dialog (e.g. VPN) or applications putting a "Fullscreen" switch into the app menu. So I tend to either drop this altogether or return to limiting the behavior to switches that are known to reveal/hide further items in the menu (bluetooth, wifi)
(In reply to comment #16) > So I tend to either drop this altogether or return to limiting the behavior to > switches that are known to reveal/hide further items in the menu (bluetooth, > wifi) Add a11y, Network Kill Switch, and Notifications switch to that list and I'll be happy.
Created attachment 235524 [details] [review] popupMenu: Optionally leave menu open after activating switch Slightly modified version of the original patch.
Created attachment 235526 [details] [review] status: Do not close menu after activating some switches (In reply to comment #17) > Add a11y, Network Kill Switch, and Notifications switch to that list and I'll > be happy. The first two don't make any sense to me. I'm not really happy to have different switches behave differently, but hopefully "does something to the menu itself" is not that unobvious to confuse the hell out of users. That reasoning does not apply to anything in the a11y menu, or any of the NMDevice switches in the network menu (I'd really say that the difference between the device switches and the VPN one boils down to "triggers a password dialog for fmuellner"). The Notication switch will affect the presence switcher in the menu, so I guess you can argue for leaving it open ...
Ping?
If I turn the Network killswitch back on, I have to go back to the menu to pick a network, usually, as I'm in a new location and none of my saved SSIDs matter.
Can we get to an agreement here ?
Turning on the network may trigger a system modal, which is worse IMHO than the current inconvenience, so I'd only include the switch if we can make popup menus close automatically when opening a moral dialog.
as opposed to an amoral dialog ? :-)
*** Bug 704275 has been marked as a duplicate of this bug. ***
any decision on this ?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.