So that the property editor always changes tab depending on the viewport/outliner selection?
You misunderstood me - I was talking about selecting things in the Outliner and You make it by clicking a data block’s icon or its name.
Hi @natecraddock, Thanks for improving the outliner.
Since a few days, in the latest 2.81 master builds, I’ve worked on a scene where clicking on an object name in the Outliner doesn’t select the object in the scene. Only clicking on the object itself in the 3D viewport selects it.
I can share the scene with you, but I’d rather not do it publicly. What’s the best way to share it privately with you?
I don’t have time to read through and see if this has been suggested, but I keep being stung by this.
If an object is in edit mode, it would be nice if when you select another object in the outliner, it exits edit mode and selects the new object. I guess exiting edit mode isn’t 100% necessary, but in cases where you select something that doesn’t have an edit mode (lights and cameras) exiting edit mode would be required.
The current behavior is mainly weird when you have a large scene and try to make a mutliselection in the Outliner. In the outliner interface, it looks like the multiselection happened - multiple objects are highlighted. But in fact, you are still in edit mode in some other object that sometimes may be off-screen in both the Outliner and the 3d View.
4 Likes
Active and selected are distinct concepts, even within the 3D view. If an object in the 3D view is active, but not selected, it will not be moved, rotated, or scaled for instance. So a deselect all in the outliner really does deselect all, but it doesn’t deactivate. The concept of an “active” item is actually common, yet hidden in other applications. Look at a file browser for instance, selecting many folders/files with ctrl+click will select the items, but a shift+click to select a range of items will operate from the last ctrl+clicked item (the active file/folder).
In Blender having an active object is important. The active object determines which object is the parent, and which are the children when parenting inthe 3D view. You can even parent to a not selected, but active object.
Simply put, selecting with just a ctrl+LMB or just LMB in the outliner will activate. Box, range, and walk select don’t activate. Box select could activate the first object in the list, it would be very simple to do. But to keep consistency with the UI, activation will be limited to the click to activate.
Thanks for reporting, I’m looking into that currently. I believe it is related to the versioning code, the code that runs when Blender tries to convert files from older versions. To ensure the new theme colors are set, the versioning code will apply the colors. I’m pretty sure this will be resolved in the official release, but I may be wrong. If there is something I can do now, I hope to have it fixed within the day.
That’s a nice idea. I’ll make a proposal for that. And the bone selection you mentioned is also related to mode switching.
That is the hope. Currently it always updates to the active object, so it makes sense to have it update to the active object’s selected datablock in the outliner. Because outliner’s don’t activate with selection syncing disabled, properties syncing also wouldn’t function with selection syncing disabled.
@MetinSeven replied in a private message
Mode toggling is being discussed and developed right now. My branch added selection syncing, but it is built on top of an older Outliner system that needs some deeper revising. We will take these suggestions into consideration to make it more intuitive 
4 Likes
Hi Nate,
I really like how the outliner is developing, you’ve really done a great job here. I just disagree with the above argumentation to some extent.
The concept of having an active object has for sure its advantages to it, and I would not want the active object mechanism to disappear, but the argument of consistency with the ui is broken in other cases too and that for a good reason.
In the 3Dview additional objects get selected with Shift+LMB but in the Outliner that is done by Ctrl+LMB. And the same two different clicks are needed if you want switch the active object with a selection already present. That’s also inconsistent.
It’s just that there’s nothing wrong with that inconsistency. Both controlschemes are something like a dominant scheme in their usecase among so many tools out there. It’s a tradeoff, you could have decided for consistency among the ui here too, but you’ve chosen to do it differently and go with defacto standards to flatten the learning curve.
So we could also allow the box selection to change the active object and the 3dview handles it differently.
Also consistency would be kept if box selections could change the active object in 3d view and the outliner.
Another thing would make the Selection / Active Object usecase even simpler:
What if the active object would have to be part of a selection. At least as a user pref option.
It would be following the same argumentation as the case above. It’s like that in so many tools, eg. your file browser usecase is like that. There are some drawbacks that go with this, that’s true, but I’d say the advantages are definitely more.
- Jc4d had the examples of entering edit mode. Four elements are selected, five enter edit mode.
- His second scenario is that nothing is selected, but one enters edit mode.
- Another drawback is you have to remember lots of different scenarios with different rules,
eg. Entering edit mode includes selection and active object, but moving elements in the outliner tree ignores the active object. - You have four objects selected and a fifth object is the active one but not selected. Thats is useful as you said eg for parenting. But if you want to change that active object, you can’t without selecting it, as the controlschemes are intertwined here, even if the concepts of selection and Activation are distinct.
- Currently the active object is just very decent highlighted, in the outliner aswell as in the 3dview, and so I guess many of us are entering edit mode are subconsciously selecting the object we’d like to edit before we enter edit mode as its faster than the time needed for orientation.
So what if the active object would have to be part of the selection, with rules like these:
- The active object would be still marked in the outliner and in the 3dview, so it would be as visible as it is now.
- The active object would be deactivated on deselection
- No object would be active, if no object is selected
- If the active object would be deselected, then the active object marker would be applied to a default candidate maybe the first one of the remaining selection,
- The active object could always be fixed/chosen manually, by a ctrl+LMB click
The result would make all the cases above easier to understand, and easier to read in the outliner. The only drawback is that sometimes there would have to be one more item have to be part of the selection, the active object.
I know that this is no easy decision as it has been different in blender for a long time, but as right now is the moment where you are discussing all these refinements with the outliner, its edit mode, etc internally, this might be the moment to discuss the active object mechanism too. But I see this is not just a discussion about the outliner, sorry for that.
4 Likes
Your proposal would be very welcome and way less confusing (and tbh annoying) than the current “active but unselected” status. Having it to be selected for being active doesn’t seem that limiting to me.
Let’s hope the core devs won’t shy away from a dramatic change like this.
2 Likes
Good idea for parenting workflow.
I agree with all your presented points.
If this conversation starts somewhere I would love to be pointed out there to follow the discussion.
1 Like
I think Some tools in blender expect something to be active for them to work, Which means that something needs to be active at all times. If you deactivated selection without activating something else some tools will stop working and the user will not be able to tell why.
@Debuk I do understand your points. When I was first starting the summer of code I had included some logic to make the first element in the outliner active if no active element existed. (this is for walk, box, and range select). I had a discussion with my mentor after that where he told me to stick to the conventions unless there is a good reason not to.
I’m not saying this is a bad conversation, but I feel like the scope of activation is beyond just the outliner. It could be changed, but it would require changes throughout Blender. Totally feel free to start a new topic https://devtalk.blender.org/c/user-feedback.
As @myway880 mentioned, many tools expect an active object. I think it would be weak to make arbitrary decisions for outliner activation. (like make the first element in box select active. What if the first is a collection? Do you activate the element, or activate the first object in the tree after that?).
Imagine this: Deselect all in the outliner deactivates. Then I box select a group of meshes in the 3D view for muli-object editmode. Then I press tab to toggle editmode… and nothing happens (because I don’t have an active object). I think it is best to stick to an intentional activation with selection.
1 Like
Hi Nate, I am aware of the fact, that this cannot be handled just inside of the outliner’s code to get a result as expected and I didn’t expect from you to solve it alone. I also can understand your mentors advice to stick with trodden pathes in terms of ui behaviour, as long as you just try to embed a “new feature” into an existing ecosystem.
I posted it here, as the discussion started here with jc4ds comments on unexpected selection behaviour. I assumed you would be part of the discussion on the ui internally where the scope for changes may be bigger than just the outliner. The case was initially addressed by @jc4d to you, so I tried to convince you and still hope I can. Maybe you can bring it up in a fitting upcoming discussion. I’ll promise this will be my last comment on that topic in this thread and I am sorry for having been partially offtopic. If there is some kind of interest in this discussion I will open up a new thread in the place you said Nate. Thanks anyhow for your time.
Glad you’ve chosen this example. I assume what you described is currently really the resulting behaviour. And I see what you mean, but in fact it just shows the drawbacks of the current system. There is code that expects an active object for the activation of an multi-object editmode. Does this make sense for you from a pure logical standpoint? Most likely not. It’s just that the code for changing to editmode currently needs it, because the active object has to be taken care for all the time. You will most likely not say that any good selection should have a separate Active Object that needs to be handled additionally. And so currently there are much more cases to handle for every single operation , even if the tools logic says its not needed at all in this case, it’s needed because the active Object exists autonomously.
If the ui would be that way that the active object would have to be part of a selection the code for entering multi object editmode could be simpler here. Switching to edit mode just needs a selection not an active object. That is only the case if there may be an active object that is not part of a selection.
Another problem with your example is that you partially got me wrong. There is never a case allowed in my proposal for an existing selection without an active object. So your box selection case would also set an object active. And because of that the current case would most like not lead to that faulty behaviour. And as you said, the user would normally select the meshes he tries to edit. Many users will not take an extra look at the current active object in this case. So the selection given to the code is “cleaner” in my case than in the one you are defending. Your active object is more likely not fitting. Anyhow the current code has to be able to rule out wrong selections, thats never gonna change.
Sure there may be problems that arise from any arbitrary choice for the active Object. But there is almost no difference in the current situation. If I just make a box selection on 3 meshes and had a light selected before as active object the code has to ignore that light. And so the code for wrong active Objects must already exist. The only new case is, what if there is no selection at all. And hopefully this case can be handled more globally.
The current situation is potentially as weak as long as you don’t manually fix the active object and that can be done with my proposal in the same way.
Instead its benefitial for code complexity and for the user interaction. Lets say the user makes a selection. If he triggers a tool that needs an active object, like parenting he is taking care of that with his selection, if there is an operation that does not need it he will most likely not take care of the current active object and just think about his selection. But currently it will be used even if it is not part of the selection and that may lead to a wrong result. Otherwise this cant happen. Till now the user has to take extra care of the Active object every time and/or the developer with every individual tool/operation too.
The argument you and @myway880 brought up is, that many existing tools might cancel their operations without a feedback if there is no active object. That may be true to some extent, at least if you would just change it inside of the outliner. But the question generally is not so much if there are code adaptions neeccessary in other parts of the blender code base. It’s more about is there an strict and easy way to get this changes done fast and is the new system better or is it not.
And I hope I am not wrong if I say it’s most likely something like an isolated case whenever it occurs with stereotypical adaptions needed. Does this tool use a call to get the active object. No, then no changes are needed at all. If yes, then does it really still need it? If no, remove the additional handling of the active object ( for the “Selection includes Active Object”-Scenario), if yes then give add some chosen type of user notification that he has to take a look at the current active object before canceling the current operation.
There are many ways to inform the user about a wrong active object chosen. Make the 3dview flicker red, make an android like toast message, notify within the status bar. Make a notification in the outliner ( yes i know thats no existing feature).
I see that there may be quite some places that need this kind of rework, but in a long term perspective it’s easier for the user and for development if active objects are just used if they are needed.
1 Like
This is a very interesting issue. Is there really a tool in Blender that doesn’t work without an active object, where a user would still expect it to work even though not having selected anything?
@natecraddock Is there an option to turn off those “blue” highlights?
I personally find them unnecessary (and noisy) since the text already change colors when selected.
Maybe an alpha value would do the trick?
8 Likes
+1
does camera icon work properly?
have currently tested latest build and have noticed that the camera icon changes active camera as intended, but still doesn’t quit camera view when it is clicked again. was this intended? just felt a bit odd since it has similar color indication as a mesh icon, which changes into Edit Mode and back when clicked again.
1 Like
No worries about being off-topic, this is a place for discussion, though if you want to continue the conversation, it would be best to take it somewhere else.
Yes it does make sense, otherwise, which type of edit mode would be entered? Mesh edit mode? Armature edit mode? Lattice edit mode? These are all very different modes with different operators. If I had a group of selected meshes, armatures, and empties (with no active) and pressed tab to toggle editmode, which editmode would I toggle to? This adds more code complexity, and arbitrary decisions. Active objects make this an intentional and obvious which mode will be entered.
This is another example of arbitrary activation then. If I box select in the 3D view, how is it decided which to activate? Alphabetically? Closest to the origin? Mesh type? A decision would have to be made in code, and then if you don’t like which object was activated you have to change it, every time.
There is no code for wrong active objects, box select just doesn’t set/change active objects at all, it simply selects.
In short, active objects give context to the tool or operation, its not a form of selection. It is an intentional interaction method to inform Blender how to perform a task. I activate an armature before tab for edit mode so Blender knows I want armature edit mode, disregarding other object types I have selected. I hope this makes sense, and why I don’t think this will change. But hey, I’m not the most experienced developer here by far, so if you want to continue the conversation, make a new topic where this is likely to be noticed by other developers.
3 Likes
Not currently. We could add alpha to the theme, or add the highlights as a filter option. I’ll make note of this.
It works as I coded it, which may not be how you expect it to work. We are redoing mode toggling and activation right now, so this behavior of toggling into and out of camera view might be included. Right now clicking on camera data neither enters into or exits camera view.
6 Likes
I’m really impressed with all your work, thanks!
1 Like
I’d vote for the alpha in the themes. It’s more consistent with the other options.
7 Likes