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.
