Page MenuHome

UI: Change Behavior for Multi-Select Enums
AcceptedPublic

Authored by Hans Goudey (HooglyBoogly) on May 29 2020, 6:21 PM.

Details

Summary

Many enums in Blender are able to have multiple items selected, but this feature isn't exposed very well.
It's not clear which enums support this, so you have to try by pressing shift when clicking on them.
And a lot of the time it's more valuable to have multiple items selected, but it's harder because of the modifier key.

A more straightforward solution is to use the multi-select behavior by default, only turning off all other items off when a modifier key is pressed.
This patch proposes this changed behavior with ctrl as the modifier key.

Before with No Modifier KeysBefore with Shift
After With CtrlAfter with No Modifier Keys

Diff Detail

Repository
rB Blender
Branch
multi-select-enums (branched from master)
Build Status
Buildable 8313
Build 8313: arc lint + arc unit

Event Timeline

Hans Goudey (HooglyBoogly) requested review of this revision.May 29 2020, 6:21 PM
Hans Goudey (HooglyBoogly) created this revision.
Hans Goudey (HooglyBoogly) planned changes to this revision.May 29 2020, 6:31 PM

This makes a lot more sense if we can add something like Hold Ctrl to clear selection automatically to tooltips for these buttons. I'll look into that.

  • Change multi-select enum tooltips to give hint about ctrl-click
This revision is now accepted and ready to land.Jun 3 2020, 12:24 AM

Although I'm fine with changing this for cases like the snapping target, it does feel a bit inconsistent. E.g. why does the snap target behave like this, but not the component selector (vertices, edges, faces)?
I don't think we should change the latter, but without looking at the code I can't predict which items are affected by this change and which not.

Although it's not very clear already. This just changes the "unclear" behavior to make a little more sense.

I thought about some visual change too, but the one that I felt made most sense[1] didn't seem feasible because of all of the hardcoded "enums" like the selection mode buttons.

[1] Highlighting every button on mouse-over in regular enums (the ones that aren't affected by this patch)

@Julian Eisel (Severin) - does feel a bit inconsistent. E.g. why does the snap target behave like this, but not the component selector (vertices, edges, faces)?

I'm (currently) of the mind that we should consider making this change AND also do it for other related things like component selector (vertices, edges, faces) at the same time, but for 3.0. As in plan for it now, announce that change soon, but not flip that switch until 3.0. So we all have a long time to get used to it coming.

I don't even mean visualizing it in Blender. Of course that would be nice but I think it's fine without it.
But at least for the patch/commit description it would be good to explain which cases this change applies to. E.g. my first thought was that it actually does affect the vert/edge/face toggles.

@Harley Acheson (harley) I don't think this should apply to the edit mode selection mode toggles at all, which are a different kind of control. You almost never want to combine them, and at lease it should not be the default.

This doesn't have to wait for Blender 3.0, we can address it for 2.90 just fine.

Is this not just reinventing the wheel, the wheel in this case being 'checkboxes', which are already used elsewhere, and more visually clear?