Page MenuHome

Outliner selection behaviour changement bug
Closed, ArchivedPublic


System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 436.48

Blender Version
Broken: version: 2.82 (sub 0), branch: master, commit date: 2019-10-15 12:59, hash: rB6934688f2ca1
Worked: (optional) Before outliner commits iirc (the commits from Nathan Craddock if I remember correctly.

Short description of error
The behaviour to select several objects in outliner changed.

I don't know if this is a bug.

Exact steps for others to reproduce the error
In 2.79b, when you were selecting several objects in outliner with shift + left click, the last object selected became the active object (OBACT(view_layer) maybe?).
In 2.8, we have not the same behaviour when we select multiple objects with shift + click.
This issue is happening since Nathan Craddock commits about outliner iirc (not 100% sure).

Here is a GIF to illustrate the issue:

Parenthesis: I am using 2.7 keymap if others can't reproduce the issue



Event Timeline

Confirm, since 2.81 beta, indeed, shift+clicking doesn't change the active object. Ctrl-clicking does though. Maybe the author could put a bit more info on the new control scheme into release notes?

@Nathan Craddock (Zachman) (cc @William Reynish (billreynish)) is this a valid report?

In fact I may even expect arrow up/down in outliner to change the active object, any reason why the design didn't go this way?

@Dalai Felinto (dfelinto) when designing the range select (shift + left click) I based the behavior on file browsers I had handy. One element must remain "active" from which to extend the selection over a range. I chose to not modify the current active object. If the last selected element (with shift) became active, then a subsequent range select would start from that element. So this isn't a bug, just how the behavior was designed. This is how shift+click works in other applications, so I don't think it should be changed. (VSCode for example)

The walk navigation originally did activate the object, but there were too many issues so I had to only move the selected. For example, walking over object data would toggle edit mode. D5817: Outliner: Selection refactor would allow for walk navigation to move the active, as the functions for activation and mode toggling are separated.


I think the common confusion is that shift+click used to be extend selection, but now it is range and ctr+click is to extend. If the issue is big enough, the modifier keys could be switched for the Blender keymap, but left as-is for the industry standard keymap.

@Nathan Craddock (Zachman), not quite. The common confusion would be that in Blender (not other applications), shift+click is indeed "extend selection" not just in Outliner, and it activates the clicked item. It works like so in viewport, Object and Edit modes, in node editor, in graph editor, pretty much in any other editor. Which object/element is "active" matters in Blender, and matters a great deal, so does being able to set it. "Choosing" to not modify it for convenience of implementation and thereby breaking the common selection pattern used throughout the application is... questionable.

@Stanislav Blinov (radcapricorn) I replied on that other task, but I think the problem mentioned in T70852: 2.81 Outliner: using active object as anchor for shift-selection is fragile as it may become hidden in outliner is the same here. Again, I don't think this is a bug, but I'm curious what @William Reynish (billreynish) and @Dalai Felinto (dfelinto) think about this.

Ulysse Martin (youle) closed this task as Archived.Fri, Oct 25, 10:30 AM
Ulysse Martin (youle) claimed this task.

I close this since we can use ctrl + click and that it is more a design decision, and can be discussed another time.