Confusing selection states in Outliner and Viewport

Archive
1

I believe that a lot of usability issues and bugs are caused by two simultaneous concepts for selection: The Outliner has its own selection state that is inconsistent with the View-port selection. This leads to…

  • the need for multiple selection indicators (blue background vs. orange)
  • inconsistent behaviors of operations in View-port vs. Outliner
  • a weird coupling of selectability and view port-visibility (hidden objects can’t be selected an thus not used with bpy.context.selected_objects)
  • inconsistent tools (e.g. it is not possible to toggle the visibility of a selected set of meshes, because a hidden mesh can’t be selected. So they can’t be unhidden)

As a user I find this behavior very confusing and I assume, that it is mainly caused by legacy. Even if there are useful tasks that require such a behavior, I personally believe that it doesn’t justify the overhead in complexity).

Consider the following bug in 2.82.7: Dragging a nested set of objects into a Collection fails (they are linked instead of moved), because “Select hierarchical” doesn’t “select” the objects in the Outliner (they are orange but not blue). Even worse, after triggering Undo, the objects are correctly selected in Outliner and Viewport. This kind of bug seems to be a logical implication of implementing the same thing (selection) multiple times:

outliner-2837-collection-bug

Also, I would love to implement AddOns for grouping etc, but the selection-state of the Outliner is no fully exposed in the python API.

Would it be possible to completely replace the Outliner’s selection state with context.selected_objects?

2 Likes
2

Here is a nice post by @Werwack that is very relevant to the issues you brought up here.
I wonder what’s the devs opinion on these matters. Is it something you’re aware of? Any plans of fixing it?

3

Thanks for the link. It sounds like exposing the Outliner selection to the python API might be possible. Fingers crossed.