Keep menus open while clicking on checkboxes.
(from the todo: http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface)
This is for the UI guys to agree on, but personally am very against this change.
- Operators which happen to have checkbox icons will behave differently to settings which happen to show in menus.
- Menu items behaving differently from each-other in general its erratic from user perspective.
- not to follow other applications blindly - but QT/GTK... for example, don't do this.
One technical concern. is that its possible pressing a button will change the context (enable/disable other items),
however currently the menu's dont redraw after pressing a button (as a panel would).
This may seem obscure but isn't exactly a corner case if you consider how many buttons in panels grey out or control the display of other buttons.
Operators which happen to have checkbox icons will behave differently to settings which happen to show in menus.
How so? Checkboxes don't close the F6 popup or redo panel either.
not to follow other applications blindly - but QT/GTK... for example, don't do this.
True. Though I think checkboxes in menus are used a lot more in Blender than any other app. For instance, the timeline has a menu that is all checkboxes.
Menu items behaving differently from each-other in general its erratic from user perspective.
With this patch, there would be only 3 types of behaviour: operator, submenu and checkbox.
One technical concern. is that its possible pressing a button will change the context (enable/disable other items), however currently the menu's dont redraw after pressing a button (as a panel would).
This is something to look at in more depth. I think most checkboxes live in "view" menus, so they don't change context that much.
Note, I couldn't find this item in: http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface
It's in the UI Widgets header, beneath Todo, 7th item from the top.
"Clicking a check box inside a menu shouldn't close it."
I'm split. I share some of the same concerns as @Campbell Barton (campbellbarton), namely the erratic behavior. However, I'd say it's even more erratic to have check boxes behave differently in menus than they do anywhere else.
Check boxes, in my opinion, should never be used to confirm any kind of action, such as a button might be. Instead check boxes should be used to enable/disable a property of an action, and in that light they should not close the menu because in many cases the user will be using the checkbox(es) to adjust some property of some action and may need to do so multiple times.
With that said, I personally think checkboxes should never be inside a menu. I don't have a better proposal on where to put them in these cases, either, though.
Am not saying that a different kind of menu behavior is necessarily bad, this is a demo of a gnome3 app, they're doing some interesting UI design.
Just that I wouldn't accept this patch in its current form - changing menu behavior for check-boxes only.
|(example usage - gif)|
I took a look around the editors and it seems most of the checkboxes are in view menus, except the playback menu in timeline, and search in outliner which are all made of checkboxes. In all cases they are used for some kind of setting, not actions.
I think the ones in view could be moved into n-panels, not sure about timeline/outliner. Maybe @Paweł Łyczkowski (plyczkowski)'s Quick Settings Popup would be a better solution for this kind of settings.
@Campbell Barton (campbellbarton) Gnome uses two different behaviors too. In Nautilus (3.16) checks and radios don't close the popup-menu, but the "refresh" button does. The 3-line menu in Builder works like that too.
@Diego Gangl (januz), that gtk3 does it does it differently, isn't justification. Just an example of how it might work.
Even the way they are presented isn't quite like a typical application menu, they're more like a kind of pop-up panel (not as visually connected to the button that opens them).
This is more of a design task then a patch review if we want to change menus behavior.
@Campbell Barton (campbellbarton) It's not justification, just saying it's not something so uncommon that it would confuse users.
I really thought this was something already decided back in the 2.5 days, just nobody had the time to do back then. Maybe it's best to let this patch alone until there's a design task and the team makes an official decision.