Currently, this still uses the same indication method as before, it just promotes it so you can already see it while hovering:

The blue overlay does seem rather arbitrary though, and not something you would likely guess relates to selections.

Rather than this, the idea is to use outlines, to tie it into the same type of outlines we use for selected objects in the 3D View:

The same indication could be used on hover:

At the very least, we could make the blue color a theme color, so that the we could set a better default here.

@William Reynish (billreynish) : Not to be pedantic but there are lots of different ways these things could be highlighted so I think your example above needs to be a little more explicit. We have items that only support single item, some support multiple but you might choose to edit only single. Which of these do you want highlighted how and when?

To my eye, it is worth considering doing it a bit differently.

With this change we are saying that it is normal to select multiple items and act on all of them at once. Therefore I think it should have no special highlight. not on hover or on editing. As in don't highlight the normal case.

But if you are hovering over an item that supports multiple while holding down ALT I think it should get a border highlight color of active object. And then while editing it could have the color wash now seen, but in orange instead of blue. So only highlight active-only editing when chosen by holding Alt.

@Harley Acheson (harley) we can’t consider multi-object the ‘normal’ case in terms of visual indication, because:

• it can’t work for everything. Some properties don’t support this, like materials and nodes.
• when editing a value, it will then change values for many items, which is why it’s important that we communicate this
• we can only show the value itself for the active item, so it’s important that you know that changes will affect the whole selection

We’ve been over these things in the design doc which has been floating around for about a year.

In D4948#113128, @William Reynish (billreynish) wrote:

We’ve been over these things in the design doc which has been floating around for about a year.

I’ve seen those docs but have yet to see anything with sufficient depth of detail to be actionable as far as highlighting is concerned. Only lots of “perhaps” do this or that without comprehensive rules or what happens in each situation.

In your previous message above you say to change the blue to outlines that match the 3dview colours, but don’t say which ones when. Change the blue to “selected” orange because it is acting on all selected? So pressing ALT will change it to the slightly redder orange of the “active” colour? That doesn’t seem like enough distinction between those.

So I’m just saying this ALL needs to be thought through and explicitly codified before it is actionable.

@Harley Acheson (harley) I don't see the issue:

Normally, Properties only apply to the active item. The 'selected' indicator indicates that it will apply to all selected items. There's nothing ambiguous.

@Brecht Van Lommel (brecht):

It's super confusing to have a mix of buttons where you can't tell easily if it will apply to one or multiple objects.

Well, that's the point of the visual indicator, so you can easily tell. That's essentially what this patch adds.

It was very much my impression that this approach was approved, which is why the design task is marked as such.

Anyway: I at least consider this a great step forward for basic manipulation of items. It seems to work really well in testing as well, and you can easily tell which items will apply to the whole selection. It's really such a nice thing to be able to select several objects and drag the Location values to offset them, or typing in a value and having it apply to everything.

It's also so much nicer than holding Alt over an item and then hoping it will work, which is the current method.

Improvements can be made to the visual indicator, but it's already a big improvement as it is.

In D4948#113160, @William Reynish (billreynish) wrote:

There's nothing ambiguous.

I’m probably just being thick, but still don’t notice these unambiguous rule written down or mocked up for all states.

In D4948#113160, @William Reynish (billreynish) wrote:

Normally, Properties only apply to the active item. The 'selected' indicator indicates that it will apply to all selected items.

So you want to highlight (in hover and during editing) everything in “active” color, except when it would affect multiples which would use “selected” color instead? That would result in everything highlighted with very little difference between those states.

In D4948#113262, @Harley Acheson (harley) wrote:

I’m probably just being thick, but still don’t notice these unambiguous rule written down or mocked up for all states.

What 'states' are you referring to here? As I can see we have two: Properties that can apply to selection, and properties that only apply to the active item

So you want to highlight (in hover and during editing) everything in “active” color, except when it would affect multiples which would use “selected” color instead? That would result in everything highlighted with very little difference between those states.

No, that was never the plan. The idea was always that we show properties normally, unless you have multiple objects selected and you hover over a property that can affect all the selected items.

There's no need to show a special indicator for only affecting the active item, because that is the default situation.

In D4948#113272, @William Reynish (billreynish) wrote:

What 'states' are you referring to here? As I can see we have two: Properties that can apply to selection, and properties that only apply to the active item

While multiple objects are selected there are THREE states to consider.:

• properties that only act on the active object
• properties that affect all selected.
• properties that could affect all selected but you are holding down ALT to change only active

The possible ways to highlight

• border around the property
• color over entire property

The times that highlighting can occur:

• always
• whenever multiple items are selected
• on hover
• while editing

All with the important consideration that the color we use for "active" versus "selected" is not very easy to distinguish.

To help in experimenting with the design, here is a template that can be mocked up with how you might like indication to work. Three rows, showing a single object selection, multiple object selection, and multiple while holding ALT to indicate intention to edit only the active object. For each there are two properties, one that is capable of editing multiple and the other not. And for each showing regular, hover, and active states.

@Brecht Van Lommel (brecht) : ...seems quite random that some buttons apply to all selected and some don't. Coloring the buttons is not enough...super confusing...

Trying to get a handle on what parts felt funny to you. As far as I can tell the bare minimum highlighting we could do (besides none) is the following. Not in your face, and highlights the only state where an accident is destructive - changing multiples when your intent was to edit just one.

But if you need to know ahead of time which item can multi-edit then we could move to something like the following and have some highlight when not hovering.

The next step I think requires us to show a difference between single and multi. Unfortunately our default colors aren't different enough so we'd have to add something new:

With maximum highlighting being something like this:

So wondering if any of these ideas seem interesting or are they all still random and confusing.

There are a large number of in-betweens as well that are fairly logically consistent - which is why I added that blank template above.

Of all the combinations I think I personally find this one the most interesting as it highlights only with multiple selection. Doesn't add noise for single. Has a nice visual change when holding or releasing ALT.

Trying to get a handle on what parts felt funny to you. As far as I can tell the bare minimum highlighting we could do (besides none) is the following. Not in your face, and highlights the only state where an accident is destructive - changing multiples when your intent was to edit just one.

The problem for me is not with the styling of individual buttons, but how if you look at all buttons in a properties editor tab, only some will work on all selected objects.

For example in the Object properties, the context path, datablock selector, Collections and Custom Properties apply only to the active object. Other panels like Transform and Visibility will apply to all selected objects. Instancing applies to all selected objects as long as they have the same instancing type.

The same issue exists for all panels with operator buttons and lists. It may for example be acceptable to grey out such panels when multiple objects are selected. But we should not stumble on such cases one by one and try to figure out a solution for each. There should be an overarching design for this, what the steps are to get there and what the UI / implementation / performance consequences of that are. Without that design we can not move ahead with this.

In D4948#118776, @Brecht Van Lommel (brecht) wrote:

Trying to get a handle on what parts felt funny to you. As far as I can tell the bare minimum highlighting we could do (besides none) is the following. Not in your face, and highlights the only state where an accident is destructive - changing multiples when your intent was to edit just one.

The problem for me is not with the styling of individual buttons, but how if you look at all buttons in a properties editor tab, only some will work on all selected objects.

For example in the Object properties, the context path, datablock selector, Collections and Custom Properties apply only to the active object. Other panels like Transform and Visibility will apply to all selected objects. Instancing applies to all selected objects as long as they have the same instancing type.

The same issue exists for all panels with operator buttons and lists. It may for example be acceptable to grey out such panels when multiple objects are selected. But we should not stumble on such cases one by one and try to figure out a solution for each. There should be an overarching design for this, what the steps are to get there and what the UI / implementation / performance consequences of that are. Without that design we can not move ahead with this.

Forgive me if I've missed something, but isn't that what the visualization solves? I mean, that was the intention. We don't and cannot support this for everything, in which case we need some sort of indication, when you have multiple objects selected.

Forgive me if I've missed something, but isn't that what the visualization solves? I mean, that was the intention. We don't and cannot support this for everything, in which case we need some sort of indication, when you have multiple objects selected.

I don't consider a different color when the mouse hovers the button to be enough. The color isn't self-explanatory, and finding out only after you've moved your mouse over the button is too late in my opinion. Surely other software handles this in a better way?

I want there to be a design document explaining how we want this to work ideally. Maybe we'll have to make some trade-offs, but then I want them to be decided rather than stumbled upon later. Otherwise we're adding a bunch of technical debt without anyone assigned to solve it. I don't want a repeat of the single column layout, where a seemingly simple change requires lots of unplanned developer time after.

Basically for every type of UI element, I want a design for how it should work ideally with multiple objects.

• Context path
• Lists and associated operators
• Datablock selector
• Material slots and assignment
• Modifiers
• Custom properties panel

Maybe the proposal is just to have those difficult case just work as if there is only an active object. But then still that's confusing to me. Perhaps each properties tab could work on either the active object or all selected objects and indicate as such in the context path.

In D4948#122650, @Brecht Van Lommel (brecht) wrote:

Forgive me if I've missed something, but isn't that what the visualization solves? I mean, that was the intention. We don't and cannot support this for everything, in which case we need some sort of indication, when you have multiple objects selected.

I don't consider a different color when the mouse hovers the button to be enough. The color isn't self-explanatory, and finding out only after you've moved your mouse over the button is too late in my opinion. Surely other software handles this in a better way?

Yes it is somewhat weak if you only see this on rollover. We could display the indicator permanently, as soon as you have > 1 selection.

I want there to be a design document explaining how we want this to work ideally. Maybe we'll have to make some trade-offs, but then I want them to be decided rather than stumbled upon later. Otherwise we're adding a bunch of technical debt without anyone assigned to solve it. I don't want a repeat of the single column layout, where a seemingly simple change requires lots of unplanned developer time after.

Ok, I'll update the design document.

Basically for every type of UI element, I want a design for how it should work ideally with multiple objects.

• Context path
• Lists and associated operators
• Datablock selector
• Material slots and assignment
• Modifiers
• Custom properties panel

Maybe the proposal is just to have those difficult case just work as if there is only an active object. But then still that's confusing to me. Perhaps each properties tab could work on either the active object or all selected objects and indicate as such in the context path.

Right, that's fair. I'll update the design doc with more specificity

Are there any plans to continue developing this?