Outliner: Double click on icon to select contents/hierachy #99275

New Issue

Julian Eisel · 2022-06-29T17:52:24+02:00

Julian Eisel commented

2022-06-29 17:52:24 +02:00

Motivation

Users often want to select all objects in a collection, or all (direct or indirect) children of an object to transform them together, or apply different operations. For this, the Outliner context menu already provides Select Objects when right-clicking on a collection, and Select Hierarchy when right-clicking on an object. Since these are such common/useful operations, faster access would be a good quality of life improvement.

Design

Double clicking on the icon of a collection should select all contained objects, even those contained in nested collections. I.e. execute the Select Objects logic. The collection itself does not need to be selected (although it might be fine to do it).
Double clicking on the icon of an object should select the hierarchy including the clicked on parent object. Ie. execute the Select Hierarchy logic.
The collapsed or opened state of tree elements should be ignored. So the children should be selected when double clicking on an object for example, even if the object element is collapsed and thus doesn't show its children in the Outliner.

Note that both cases are an operation acting on the entire hierarchy, so they are recursive. With the difference that the first doesn't keep the clicked on element selected, while the second does. Other than that these are consistent operations.

Corner Cases to Consider

If an object has a child that is not in the same collection as the parent, double clicking the collection icon should not select that child object. Only the objects actually contained in that collection (directly or indirectly) should be selected.
Ideally: When objects or collections are linked into multiple collections, only the hierarchy that was clicked on should be selected in the Outliner, not the other occurrence of it. This is better explained visually: outliner_select_multi_link-2022-06-29_17.42.42.mp4 Note how even though the Suzanne object gets selected properly (orange font), only the clicked on Outliner element gets selected (blue element highlight). Note that the existing Select Objects and Select Hierarchy don't behave this way, they select all occurrences in the Outliner. Therefore this is more of a nice-to-have feature.

Implementation Notes

An new operator can be added that is invoked with a double-click in the Outliner, checks if the cursor is over a relevant icon, and executes the logic then.
The last corner case mentioned above (with the video explanation) can be done by selecting the tree element and updating the object selection from this with ED_outliner_select_sync_from_outliner(). If done the other way around (object is selected and outliner tree is synced from that), all occurrences would be selected in the Outliner. This is what the existing Select Objects and Select Hierachy do, and it's a bit tricky to correct that.

**Motivation** Users often want to select all objects in a collection, or all (direct or indirect) children of an object to transform them together, or apply different operations. For this, the Outliner context menu already provides *Select Objects* when right-clicking on a collection, and *Select Hierarchy* when right-clicking on an object. Since these are such common/useful operations, faster access would be a good quality of life improvement. **Design** - Double clicking on the icon of a collection should select all contained objects, even those contained in nested collections. I.e. execute the *Select Objects* logic. The collection itself does not need to be selected (although it might be fine to do it). - Double clicking on the icon of an object should select the hierarchy including the clicked on parent object. Ie. execute the *Select Hierarchy* logic. - The collapsed or opened state of tree elements should be ignored. So the children should be selected when double clicking on an object for example, even if the object element is collapsed and thus doesn't show its children in the Outliner. Note that both cases are an operation acting on the entire hierarchy, so they are recursive. With the difference that the first doesn't keep the clicked on element selected, while the second does. Other than that these are consistent operations. **Corner Cases to Consider** - If an object has a child that is not in the same collection as the parent, double clicking the collection icon should not select that child object. Only the objects actually contained in that collection (directly or indirectly) should be selected. - Ideally: When objects or collections are linked into multiple collections, only the hierarchy that was clicked on should be selected in the Outliner, not the other occurrence of it. This is better explained visually: [outliner_select_multi_link-2022-06-29_17.42.42.mp4](https://archive.blender.org/developer/F13238530/outliner_select_multi_link-2022-06-29_17.42.42.mp4) Note how even though the Suzanne object gets selected properly (orange font), only the clicked on Outliner element gets selected (blue element highlight). Note that the existing *Select Objects* and *Select Hierarchy* don't behave this way, they select all occurrences in the Outliner. Therefore this is more of a nice-to-have feature. **Implementation Notes** - An new operator can be added that is invoked with a double-click in the Outliner, checks if the cursor is over a relevant icon, and executes the logic then. - The last corner case mentioned above (with the video explanation) can be done by selecting the tree element and updating the object selection from this with `ED_outliner_select_sync_from_outliner()`. If done the other way around (object is selected and outliner tree is synced from that), all occurrences would be selected in the Outliner. This is what the existing *Select Objects* and *Select Hierachy* do, and it's a bit tricky to correct that.

❤️ 1

Julian Eisel commented

2022-06-29 17:52:24 +02:00

Added subscribers: @JulianEisel, @JulienKaspar

Dominik Fill commented

2022-06-29 18:06:15 +02:00

Added subscriber: @dominikfill

Paul Kotelevets commented

2022-06-30 00:30:13 +02:00

Added subscriber: @1D_Inc

Paul Kotelevets commented

2022-06-30 00:30:13 +02:00

Nice topic. A couple of questions though:

Does it consider the way for multiple items selecting?
Maybe something like Shift+doubleclick?

How about deselecting? (I want the entire scene selected except those two collections I organized especially to filter out)
Maybe something like Alt+doubleclick? (Shift+doubleclick the second time to deselect already selected probably will
be hard to handle, since it will depend on selected conditions, especially if collection is collapsed)

Will there be chaining action? Will it select the entire hierarchical branch of collections of a doubleclicked collection (aka "nested collections")?
Maybe something like Ctrl+Shift+doubleclick?

Also what about conventional doubleclick renaming, used everywhere (from os to softwares)?
Will it be optional or will influence only icon doubleclicking, not name text box doubleclicking?

The collapsed or opened state of tree elements should be ignored.

This will result in weak selection indication (one of the reasons it was decided to solve selection as a separate icon with multiple states in Collection Manager addon).
Probably, not critical, but not pleasant either.

A slightly offtop:

When objects or collections are linked into multiple collections,

Does it have any shorter official term?
We call this property as "cumulativity" during discussing system design at local level (for example, collection engine paradigm can be described as a "common layer paradigm - aka /photoshop layers/ - but with cumulativity". Cumulative objects, Cumulative collections and Collections with cumulative objects usually require additional handling as any other cross-hierarchical structures), but most of time at global level it is just called "when objects or collections are linked into multiple collections" each time and it seems to be quite a long term for official feature.

Nice topic. A couple of questions though: Does it consider the way for multiple items selecting? Maybe something like Shift+doubleclick? How about deselecting? (I want the entire scene selected except those two collections I organized especially to filter out) Maybe something like Alt+doubleclick? (Shift+doubleclick the second time to deselect already selected probably will be hard to handle, since it will depend on selected conditions, especially if collection is collapsed) Will there be chaining action? Will it select the entire hierarchical branch of collections of a doubleclicked collection (aka "nested collections")? Maybe something like Ctrl+Shift+doubleclick? Also what about conventional doubleclick renaming, used everywhere (from os to softwares)? Will it be optional or will influence only icon doubleclicking, not name text box doubleclicking? > The collapsed or opened state of tree elements should be ignored. This will result in weak selection indication (one of the reasons it was decided to solve selection as a separate icon with multiple states in Collection Manager addon). Probably, not critical, but not pleasant either. A slightly offtop: > When objects or collections are linked into multiple collections, Does it have any shorter official term? We call this property as "cumulativity" during discussing system design at local level (for example, collection engine paradigm can be described as a "common layer paradigm - aka /photoshop layers/ - but with cumulativity". **Cumulative objects**, **Cumulative collections** and **Collections with cumulative objects** usually require additional handling as any other cross-hierarchical structures), but most of time at global level it is just called "when objects or collections are linked into multiple collections" each time and it seems to be quite a long term for official feature.

Pablo Vazquez commented

2022-06-30 01:14:40 +02:00

Added subscriber: @pablovazquez

Pablo Vazquez commented

2022-06-30 01:14:40 +02:00

I think it will speed up workflow immensely, it's worth trying.

In #99275#1382603, @1D_Inc wrote:
Maybe something like Shift+doubleclick?
How about deselecting? Maybe something like Alt+doubleclick?

That could work.

Also what about conventional doubleclick renaming, used everywhere (from os to softwares)?
Will it be optional or will influence only icon doubleclicking, not text box doubleclicking?

The operator should only run when double-clicking on the icon. Double-click on the item's name to rename should stay as it is the way it's been since forever and it's even the only way to rename in some areas (e.g. UI Lists such as Vertex Groups).

The collapsed or opened state of tree elements should be ignored.

This will result in weak selection indication

The weak selection indication for collapsed Collections issue is already present before this patch, this change does not affect it.

If tests show that it's too unclear we could go for something similar to the highlight for active items, but using the color for selected objects in the Outliner/Viewport (quick mockup).
{F13239953, size=full}

I think it will speed up workflow immensely, it's worth trying. > In #99275#1382603, @1D_Inc wrote: > Maybe something like Shift+doubleclick? > How about deselecting? Maybe something like Alt+doubleclick? That could work. > Also what about conventional doubleclick renaming, used everywhere (from os to softwares)? > Will it be optional or will influence only icon doubleclicking, not text box doubleclicking? The operator should only run when double-clicking on the icon. Double-click on the item's name to rename should stay as it is the way it's been since forever and it's even the only way to rename in some areas (e.g. UI Lists such as Vertex Groups). >> The collapsed or opened state of tree elements should be ignored. > This will result in weak selection indication The weak selection indication for collapsed Collections issue is already present before this patch, this change does not affect it. If tests show that it's too unclear we could go for something similar to the highlight for active items, but using the color for selected objects in the Outliner/Viewport (quick mockup). {[F13239953](https://archive.blender.org/developer/F13239953/image.png), size=full}

Paul Kotelevets commented

2022-06-30 15:48:19 +02:00

In #99275#1382614, @pablovazquez wrote:

In #99275#1382603, @1D_Inc wrote:
Maybe something like Shift+doubleclick?
How about deselecting? Maybe something like Alt+doubleclick?

That could work.

Sweet.
Thank you for the answer.

> In #99275#1382614, @pablovazquez wrote: > >> In #99275#1382603, @1D_Inc wrote: >> Maybe something like Shift+doubleclick? >> How about deselecting? Maybe something like Alt+doubleclick? > That could work. Sweet. Thank you for the answer.

Brad Clark commented

2022-06-30 23:06:08 +02:00

Added subscriber: @BClark

Brad Clark commented

2022-06-30 23:07:10 +02:00

Yes, I have to select by hierarchy through the menu way too often, I would love to have a better select all in collection action.

Mohammed Salman commented

2022-07-02 16:45:57 +02:00

Added subscriber: @msal

M. Grady Saunders commented

2022-07-03 21:45:26 +02:00

Added subscriber: @mgradysaunders

M. Grady Saunders commented

2022-07-03 21:45:26 +02:00

I thought this seemed like a great feature and reasonable first project, so I'm taking a crack at implementing it. I think I have things working as intended, minus the corner case (looking into that now). The diff is at https://developer.blender.org/D15351. Here's a quick demo. Feedback is welcome and appreciated.

demo.mp4

I thought this seemed like a great feature and reasonable first project, so I'm taking a crack at implementing it. I think I have things working as intended, minus the corner case (looking into that now). The diff is at https://developer.blender.org/D15351. Here's a quick demo. Feedback is welcome and appreciated. [demo.mp4](https://archive.blender.org/developer/F13255584/demo.mp4)

Andy Cuccaro commented

2022-07-04 00:31:08 +02:00

Added subscriber: @AndyCuccaro

slwk1d commented

2022-07-04 11:48:16 +02:00

Added subscriber: @Slowwkidd

Mangal Kushwah commented

2022-07-04 17:05:49 +02:00

Added subscriber: @Mangal-Kushwah

Santy Berrones commented

2022-07-06 02:00:50 +02:00

Added subscriber: @santbg

Santy Berrones commented

2022-07-06 02:00:50 +02:00

You might consider that a single click on the icon selects everything in the Collection, and to deselect click on the empty space.
Unless there are any drawbacks it is more intuitive and has no hidden hacks or shortcuts.

You might consider that a single click on the icon selects everything in the Collection, and to deselect click on the empty space. Unless there are any drawbacks it is more intuitive and has no hidden hacks or shortcuts.

M. Grady Saunders commented

2022-07-06 02:45:26 +02:00

At least at first glance, I think @santbg's single-click solution could tidy up the design and implementation a bit. Per the description in the diff, deselect currently works by CTRL+ALT+double-click on the icon, where the ALT is necessary to disambiguate it from an ordinary CTRL+single-click to deselect. If we just used the icon itself to distinguish whether the user wanted recursive selection, then both selection and deselection should work consistently with ordinary CTRL+single-click behavior.

Of course, there may be drawbacks I'm not considering. But I'm happy to update the diff if given the go ahead.

At least at first glance, I think @santbg's single-click solution could tidy up the design and implementation a bit. Per the description in the diff, deselect currently works by CTRL+ALT+double-click on the icon, where the ALT is necessary to disambiguate it from an ordinary CTRL+single-click to deselect. If we just used the icon itself to distinguish whether the user wanted recursive selection, then both selection and deselection should work consistently with ordinary CTRL+single-click behavior. Of course, there may be drawbacks I'm not considering. But I'm happy to update the diff if given the go ahead.

Paul Kotelevets commented

2022-07-06 18:02:11 +02:00

In #99275#1386006, @santbg wrote:
You might consider that a single click on the icon selects everything in the Collection, and to deselect click on the empty space.
Unless there are any drawbacks it is more intuitive and has no hidden hacks or shortcuts.

Then you will select collection's content instead of collection in case of missclicking, for example, when you need to move collections in the outliner.
Doubleclick prevents from this, separating selecting collection from selecting its content during fast work.

> In #99275#1386006, @santbg wrote: > You might consider that a single click on the icon selects everything in the Collection, and to deselect click on the empty space. > Unless there are any drawbacks it is more intuitive and has no hidden hacks or shortcuts. Then you will select collection's content instead of collection in case of missclicking, for example, when you need to move collections in the outliner. Doubleclick prevents from this, separating selecting collection from selecting its content during fast work.

Santy Berrones commented

2022-07-06 19:36:50 +02:00

In #99275#1386460, @1D_Inc wrote:

In #99275#1386006, @santbg wrote:
You might consider that a single click on the icon selects everything in the Collection, and to deselect click on the empty space.
Unless there are any drawbacks it is more intuitive and has no hidden hacks or shortcuts.

Then you will select collection's content instead of collection in case of missclicking, for example, when you need to move collections in the outliner.
Doubleclick prevents from this, separating selecting collection from selecting its content during fast work.

On twitter I saw that they created a new operator, in which you can assign the shortcut you want.
I don't know if it's someone from here.
https://twitter.com/CosmoMidias/status/1544498062907047936?s=20&t=4RsDLCxjwwjmVQwWEeFX8g

> In #99275#1386460, @1D_Inc wrote: >> In #99275#1386006, @santbg wrote: >> You might consider that a single click on the icon selects everything in the Collection, and to deselect click on the empty space. >> Unless there are any drawbacks it is more intuitive and has no hidden hacks or shortcuts. > > Then you will select collection's content instead of collection in case of missclicking, for example, when you need to move collections in the outliner. > Doubleclick prevents from this, separating selecting collection from selecting its content during fast work. On twitter I saw that they created a new operator, in which you can assign the shortcut you want. I don't know if it's someone from here. https://twitter.com/CosmoMidias/status/1544498062907047936?s=20&t=4RsDLCxjwwjmVQwWEeFX8g

Pablo Vazquez commented

2022-07-12 17:27:33 +02:00

After a meeting with @JulianEisel, we agreed that double-click is the way to go. Single-click is used to change context in the Properties editor, which is super handy, but more importantly it's also used to make a Collection active (without affecting selection).

Regarding modifiers, we should follow as close as possible what it's already there.

Ctrl: Adds/removes element and its hierarchy
Shift: Adds/removes elements in range and their hierarchies

The same goes for deselecting.

Here is a quick video explaining it (with audio, at 1:01 I said Ctrl when I meant Shift):
sc_-2022-07-12_17.20.04.mp4

After a meeting with @JulianEisel, we agreed that double-click is the way to go. Single-click is used to change context in the Properties editor, which is super handy, but more importantly it's also used to make a Collection active (without affecting selection). Regarding modifiers, we should follow as close as possible what it's already there. * Ctrl: Adds/removes element and its hierarchy * Shift: Adds/removes elements in range and their hierarchies The same goes for deselecting. Here is a quick video explaining it (with audio, at 1:01 I said Ctrl when I meant **Shift**): [sc_-2022-07-12_17.20.04.mp4](https://archive.blender.org/developer/F13288964/sc_-2022-07-12_17.20.04.mp4)

Julian Eisel commented

2022-07-12 17:36:44 +02:00

Another reason to avoid single clicking is that it's easy to accidentally single click on the icon, so the hierarchy would be selected rather than the single element. When the collection is collapsed there's no way to see the difference in the Outliner.

Julian Eisel commented

2022-07-12 17:39:07 +02:00

Implementation wise, I think it's fine to first get the basic logic for selecting the hierarchies ready, and then in a separate patch making that work with {key Shift} and {key Ctrl}. Otherwise it might be a bit too much to take on at once :) Of course the first patch should be designed so the second doesn't have to completely rewrite the logic again.

M. Grady Saunders commented

2022-07-13 01:06:31 +02:00

Having read the specs laid out by Julian and Pablo, I've revised my diff for this task. I'll update with arcanist momentarily, after I clean things up a little. But here is a quick demo (now with voiceover) new-demo.mp4

Having read the specs laid out by Julian and Pablo, I've revised my diff for this task. I'll update with arcanist momentarily, after I clean things up a little. But here is a quick demo (now with voiceover) [new-demo.mp4](https://archive.blender.org/developer/F13289706/new-demo.mp4)

Paul Kotelevets commented

2022-07-13 08:02:53 +02:00

Hm.
I am not agree with the original Ctrl and Shift selection assignment in the outliner - it was assigned in the way it contradicts to the rest of Blender, and probably should be swapped.
For example,

Shift is originally used for adding/removing individual items to a selection, for example, in object mode, edit mode, dope sheet, curve editor, node editor and so one.
and Ctrl is used for range selection, for example in edit mode, dope sheet and curve editor.

which is reasonable since Shift is a better accessible key than Ctrl, so it better fits more relevant operation (such as adding items to a selection) rather than less relevant operation (such as selecting a range).

Example1: Shift+LMB is used for adding/removing several individual Object transforms to a selection (adding/removing curve points also is a Shift+LMB action), and Ctrl+LMB selects curve points in a range between the beginning and current position of a cursor,

Example2: in edit mode Shift adds/removes individual vertices to a selection, and Ctrl is used for range selection (Pick Shortest Path operator)

The outliner and file/asset managers seems to be the only editors where Shift and Ctrl functionality is swapped.
I guess we reached the point it should be addressed, otherwise the outliner behaviour differentiation from the rest of a program will keep spread its inconsistency as its functionality will grow.
How do you think?

Hm. I am not agree with the original Ctrl and Shift selection assignment in the outliner - it was assigned in the way it contradicts to the rest of Blender, and probably should be swapped. For example, - Shift is originally used for adding/removing **individual** items to a selection, for example, in object mode, edit mode, dope sheet, curve editor, node editor and so one. - and Ctrl is used for **range** selection, for example in edit mode, dope sheet and curve editor. which is reasonable since Shift is a better accessible key than Ctrl, so it better fits more relevant operation (such as adding items to a selection) rather than less relevant operation (such as selecting a range). Example1: Shift+LMB is used for adding/removing several **individual** Object transforms to a selection (adding/removing curve points also is a Shift+LMB action), and Ctrl+LMB selects curve points in a **range** between the beginning and current position of a cursor, ![image.png](https://archive.blender.org/developer/F13289892/image.png) Example2: in edit mode Shift adds/removes **individual** vertices to a selection, and Ctrl is used for **range** selection (Pick Shortest Path operator) ![image.png](https://archive.blender.org/developer/F13289920/image.png) The outliner and file/asset managers seems to be the only editors where Shift and Ctrl functionality is swapped. I guess we reached the point it should be addressed, otherwise the outliner behaviour differentiation from the rest of a program will keep spread its inconsistency as its functionality will grow. How do you think?

Julien Kaspar commented

2022-07-13 10:18:41 +02:00

@1D_Inc I agree but I think for the sake of this task we can ignore this inconsistency. If the keys are swapped or not doesn't affect the functionality of this design, and merely follows existing design decisions.

I'd propose to have a separate discussion about the Shift and Ctrl key assignments.

@1D_Inc I agree but I think for the sake of this task we can ignore this inconsistency. If the keys are swapped or not doesn't affect the functionality of this design, and merely follows existing design decisions. I'd propose to have a separate discussion about the Shift and Ctrl key assignments.

Paul Kotelevets commented

2022-07-13 18:10:21 +02:00

In #99275#1389558, @JulienKaspar wrote:
@1D_Inc I agree but I think for the sake of this task we can ignore this inconsistency. If the keys are swapped or not doesn't affect the functionality of this design, and merely follows existing design decisions.

I'd propose to have a separate discussion about the Shift and Ctrl key assignments.

Okay. Indeed, even if it is tightly connected, in general it is a different topic that require different level of arguments.

> In #99275#1389558, @JulienKaspar wrote: > @1D_Inc I agree but I think for the sake of this task we can ignore this inconsistency. If the keys are swapped or not doesn't affect the functionality of this design, and merely follows existing design decisions. > > I'd propose to have a separate discussion about the Shift and Ctrl key assignments. Okay. Indeed, even if it is tightly connected, in general it is a different topic that require different level of arguments.

Paul Kotelevets commented

2022-07-13 18:24:45 +02:00

In #99275#1389496, @mgradysaunders wrote:
Having read the specs laid out by Julian and Pablo, I've revised my diff for this task. I'll update with arcanist momentarily, after I clean things up a little. But here is a quick demo (now with voiceover) new-demo.mp4

A very nice demo.
However, at some point it is highly recommended to create a scene that contains all the functional possibilities and flexibilities - including cumulative objects, cumulative/nesting/linked collections, and so one, for proper testing purposes.
When we was testing our selection tools, we created several scenes for such kind of purposes, to make sure our concept works with the most of possible cases correctly.

> In #99275#1389496, @mgradysaunders wrote: > Having read the specs laid out by Julian and Pablo, I've revised my diff for this task. I'll update with arcanist momentarily, after I clean things up a little. But here is a quick demo (now with voiceover) [new-demo.mp4](https://archive.blender.org/developer/F13289706/new-demo.mp4) A very nice demo. However, at some point it is highly recommended to create a scene that contains all the functional possibilities and flexibilities - including cumulative objects, cumulative/nesting/linked collections, and so one, for proper testing purposes. When we was testing our selection tools, we created several scenes for such kind of purposes, to make sure our concept works with the most of possible cases correctly.

M. Grady Saunders commented

2022-07-13 23:18:21 +02:00

In #99275#1389775, @1D_Inc wrote:

A very nice demo.
However, at some point it is highly recommended to create a scene that contains all the functional possibilities and flexibilities - including cumulative objects, cumulative/nesting/linked collections, and so one, for proper testing purposes.
When we was testing our selection tools, we created several scenes for such kind of purposes, to make sure our concept works with the most of possible cases correctly.

Noted, thanks. Do you happen to have a feature complete scene from a previous effort lying around for testing? I think I have the bases covered but there is a chance of a sneaky or advanced feature I'm not too familiar with breaking things.

As a quick sanity check, I just fired up blender, created another collection with a new Suzanne, then added a linked duplicate of that collection under the default collection, and also added a normal duplicate of the that collection with a parent relationship crossing between collections. The CTRL/SHIFT functionality seems to behave as expected, with nesting and either open or closed sub-objects. I'll record another video when I get a minute.

Side note: I managed to wire things up exclusively on the "layer level" as per the usual range select, i.e., working only in terms of flagging layers for selection so that everything gets picked up by the sync function later, thus bypassing the original logic used to implement the right-click versions of these. That is to say that there shouldn't many distinct code paths where things can go horribly wrong. But again I'm new, etc.

> In #99275#1389775, @1D_Inc wrote: > > A very nice demo. > However, at some point it is highly recommended to create a scene that contains all the functional possibilities and flexibilities - including cumulative objects, cumulative/nesting/linked collections, and so one, for proper testing purposes. > When we was testing our selection tools, we created several scenes for such kind of purposes, to make sure our concept works with the most of possible cases correctly. Noted, thanks. Do you happen to have a feature complete scene from a previous effort lying around for testing? I think I have the bases covered but there is a chance of a sneaky or advanced feature I'm not too familiar with breaking things. As a quick sanity check, I just fired up blender, created another collection with a new Suzanne, then added a linked duplicate of that collection under the default collection, and also added a normal duplicate of the that collection with a parent relationship crossing between collections. The CTRL/SHIFT functionality seems to behave as expected, with nesting and either open or closed sub-objects. I'll record another video when I get a minute. Side note: I managed to wire things up exclusively on the "layer level" as per the usual range select, i.e., working only in terms of flagging layers for selection so that everything gets picked up by the sync function later, thus bypassing the original logic used to implement the right-click versions of these. That is to say that there shouldn't many distinct code paths where things can go horribly wrong. But again I'm new, etc.

Paul Kotelevets commented

2022-07-14 08:00:46 +02:00

In #99275#1389842, @mgradysaunders wrote:

Noted, thanks. Do you happen to have a feature complete scene from a previous effort lying around for testing? I think I have the bases covered but there is a chance of a sneaky or advanced feature I'm not too familiar with breaking things.

Yes, here is one of those scenes we used to check overall practical collection engine setup readability and functional/navigational completeness, that's why it is more complex than basic generic setup.
https://dropmefiles.com/U727N (the link expires in a week)
Objects that represents cross-hierarchical things are created as a text objects for a better structural clarity and visual control.

> In #99275#1389842, @mgradysaunders wrote: > Noted, thanks. Do you happen to have a feature complete scene from a previous effort lying around for testing? I think I have the bases covered but there is a chance of a sneaky or advanced feature I'm not too familiar with breaking things. Yes, here is one of those scenes we used to check overall practical collection engine setup readability and functional/navigational completeness, that's why it is more complex than basic generic setup. https://dropmefiles.com/U727N (the link expires in a week) Objects that represents cross-hierarchical things are created as a text objects for a better structural clarity and visual control. ![image.png](https://archive.blender.org/developer/F13291601/image.png)

M. Grady Saunders commented

2022-07-14 14:11:07 +02:00

In #99275#1390013, @1D_Inc wrote:

Yes, here is one of those scenes we used to check overall practical collection engine setup readability and functional/navigational completeness, that's why it is more complex than basic generic setup.

Thanks! I spent some time testing things out this morning. Overall the behavior is sensible, but there's a couple things I want to demonstrate and verify. See the following video.

new-demo-2.mp4

> In #99275#1390013, @1D_Inc wrote: > > Yes, here is one of those scenes we used to check overall practical collection engine setup readability and functional/navigational completeness, that's why it is more complex than basic generic setup. Thanks! I spent some time testing things out this morning. Overall the behavior is sensible, but there's a couple things I want to demonstrate and verify. See the following video. [new-demo-2.mp4](https://archive.blender.org/developer/F13292286/new-demo-2.mp4)

Jan-Erik commented

2022-07-14 18:41:50 +02:00

Added subscriber: @JanErik

Jan-Erik commented

2022-07-14 18:44:16 +02:00

@mgradysaunders
This looks so nice! Very well done and extremely helpful. I think the recursion can stop at object level, data/materials is not needed

@mgradysaunders This looks so nice! Very well done and extremely helpful. I think the recursion can stop at object level, data/materials is not needed

M. Grady Saunders commented

2022-07-14 20:42:08 +02:00

In #99275#1390330, @JanErik wrote:
@mgradysaunders
This looks so nice! Very well done and extremely helpful. I think the recursion can stop at object level, data/materials is not needed

Thank you. And I'm guessing the behavior of stopping at the object level will be the consensus opinion. Went ahead and updated the diff with that change 👍

> In #99275#1390330, @JanErik wrote: > @mgradysaunders > This looks so nice! Very well done and extremely helpful. I think the recursion can stop at object level, data/materials is not needed Thank you. And I'm guessing the behavior of stopping at the object level will be the consensus opinion. Went ahead and updated the diff with that change 👍

Paul Kotelevets commented

2022-07-14 22:23:18 +02:00

In #99275#1390191, @mgradysaunders wrote:
See the following video.

Nice video!
2:12 - Yes, those elements are supposed to be selected like that, since they are cumulative and belong the first collection as well, so selecting this collection will also select those objects.
2:57 - About Ctrl deselection, can you show what will happen if to deselect both collections - will cumulative objects remain selected after that (we faced such kind of an issue before, so it is interesting to look at the result)

> In #99275#1390191, @mgradysaunders wrote: > See the following video. Nice video! 2:12 - Yes, those elements are supposed to be selected like that, since they are cumulative and belong the first collection as well, so selecting this collection will also select those objects. 2:57 - About Ctrl deselection, can you show what will happen if to deselect both collections - will cumulative objects remain selected after that (we faced such kind of an issue before, so it is interesting to look at the result)

M. Grady Saunders commented

2022-07-18 14:27:50 +02:00

Apologies for the radio silence, was out and about over the weekend. To address @1D_Inc's question, here is one more demo which also shows the stop-at-object-level functionality.

new-demo-3.mp4

Apologies for the radio silence, was out and about over the weekend. To address @1D_Inc's question, here is one more demo which also shows the stop-at-object-level functionality. [new-demo-3.mp4](https://archive.blender.org/developer/F13298514/new-demo-3.mp4)

Paul Kotelevets commented

2022-07-18 16:41:20 +02:00

In #99275#1392146, @mgradysaunders wrote:
Apologies for the radio silence, was out and about over the weekend.

No worries, there are no deadlines in such kind of tasks anyway)
Hierarchical functionality can ve solved only at the moment they solved.

To address @1D_Inc's question, here is one more demo which also shows the stop-at-object-level functionality.

new-demo-3.mp4

Wow, it seems you nailed cumulative elements deselection!
That is spectacular and respectable.
How did you achieved that, by the way?
Do you control if the deselected instances are last in the selection somehow?

> In #99275#1392146, @mgradysaunders wrote: > Apologies for the radio silence, was out and about over the weekend. No worries, there are no deadlines in such kind of tasks anyway) Hierarchical functionality can ve solved only at the moment they solved. >To address @1D_Inc's question, here is one more demo which also shows the stop-at-object-level functionality. > > [new-demo-3.mp4](https://archive.blender.org/developer/F13298514/new-demo-3.mp4) Wow, it seems you nailed cumulative elements deselection! That is spectacular and respectable. How did you achieved that, by the way? Do you control if the deselected instances are last in the selection somehow?

M. Grady Saunders commented

2022-07-19 14:25:38 +02:00

In #99275#1392205, @1D_Inc wrote:

Wow, it seems you nailed cumulative elements deselection!
That is spectacular and respectable.
How did you achieved that, by the way?
Do you control if the deselected instances are last in the selection somehow?

Thank you! I figure can't take too much credit, as the idea and implementation turn out to be rather simple. In other words, it hasn't been necessary to handle cumulative objects with any specialized code or anything. Here is main routine.

/* A simple but apparently effective solution for recursive selections. */
static void do_outliner_select_recursive(ListBase *lb, bool selecting)
{
  LISTBASE_FOREACH (TreeElement *, te, lb) {
    TreeStoreElem *tselem = TREESTORE(te);

    /* The desired behavior is only to select collections and object hierarchies 
       recursively. So if this isn't a collection or an object, skip it. */
    if (tselem->type == TSE_LAYER_COLLECTION ||
        (tselem->type == TSE_SOME_ID && te->idcode == ID_OB)) {
      if (selecting)
        tselem->flag |= TSE_SELECTED;
      else
        tselem->flag &= ~TSE_SELECTED;
      do_outliner_select_recursive(&te->subtree, selecting);
    }
    else {
      tselem->flag &= ~TSE_SELECTED;
    }
  }
}

This only needs to be called in a place or two, configured according to the double-click and modifier keys. Then the actual selection of objects in the scene gets synchronized to the outliner via ED_outliner_select_sync_from_outliner. Not sure what the historical bug was, but I might guess it was fixed somewhere in this routine? -- which I have not needed to modify 👍

> In #99275#1392205, @1D_Inc wrote: > > Wow, it seems you nailed cumulative elements deselection! > That is spectacular and respectable. > How did you achieved that, by the way? > Do you control if the deselected instances are last in the selection somehow? Thank you! I figure can't take too much credit, as the idea and implementation turn out to be rather simple. In other words, it hasn't been necessary to handle cumulative objects with any specialized code or anything. Here is main routine. ```C /* A simple but apparently effective solution for recursive selections. */ static void do_outliner_select_recursive(ListBase *lb, bool selecting) { LISTBASE_FOREACH (TreeElement *, te, lb) { TreeStoreElem *tselem = TREESTORE(te); /* The desired behavior is only to select collections and object hierarchies recursively. So if this isn't a collection or an object, skip it. */ if (tselem->type == TSE_LAYER_COLLECTION || (tselem->type == TSE_SOME_ID && te->idcode == ID_OB)) { if (selecting) tselem->flag |= TSE_SELECTED; else tselem->flag &= ~TSE_SELECTED; do_outliner_select_recursive(&te->subtree, selecting); } else { tselem->flag &= ~TSE_SELECTED; } } } ``` This only needs to be called in a place or two, configured according to the double-click and modifier keys. Then the actual selection of objects in the scene gets synchronized to the outliner via `ED_outliner_select_sync_from_outliner`. Not sure what the historical bug was, but I might guess it was fixed somewhere in this routine? -- which I have not needed to modify 👍

Paul Kotelevets commented

2022-07-19 18:40:39 +02:00

In #99275#1392620, @mgradysaunders wrote:
Here is main routine.

Indeed, seems to be solved with quite generic recursion. Feels strange though.
Nice job anyway)
Very functional.

> In #99275#1392620, @mgradysaunders wrote: >Here is main routine. Indeed, seems to be solved with quite generic recursion. Feels strange though. Nice job anyway) Very functional.

slwk1d commented

2022-07-20 17:34:13 +02:00

Even though I still think that selecting the hierarchy with just 1 click on the whole item (icon + name), and not just the icon would be even more intuitive, this is a huge improvement in usability, so congrats! I wanted to ask if this will be also shown as an operator in the Outliner keymap preferences, giving the user the possibility to e.g. change from dbl-click to single click?

Juan commented

2022-07-21 07:38:30 +02:00

Added subscriber: @jc4d

Juan commented

2022-07-21 07:38:30 +02:00

In #99275#1393315, @Slowwkidd wrote:
Even though I still think that selecting the hierarchy with just 1 click on the whole item (icon + name), and not just the icon would be even more intuitive, this is a huge improvement in usability, so congrats! I wanted to ask if this will be also shown as an operator in the Outliner keymap preferences, giving the user the possibility to e.g. change from dbl-click to single click?

Agree with you about having a preference for it. Suffering of carpal tunnels, double clicks are more difficult to perform and creates more restrain than singe click.

> In #99275#1393315, @Slowwkidd wrote: > Even though I still think that selecting the hierarchy with just 1 click on the whole item (icon + name), and not just the icon would be even more intuitive, this is a huge improvement in usability, so congrats! I wanted to ask if this will be also shown as an operator in the Outliner keymap preferences, giving the user the possibility to e.g. change from dbl-click to single click? Agree with you about having a preference for it. Suffering of carpal tunnels, double clicks are more difficult to perform and creates more restrain than singe click.

Jan-Erik commented

2022-07-22 11:35:08 +02:00

is there a chance, that this feature will be part of 3.3 ?

M. Grady Saunders commented

2022-07-22 13:22:31 +02:00

In #99275#1393315, @Slowwkidd wrote:
I wanted to ask if this will be also shown as an operator in the Outliner keymap preferences, giving the user the possibility to e.g. change from dbl-click to single click?

I'll see if I can figure this out. There is just 1 slight complication (with event filtering being necessary on the first click for CTRL/SHIFT clicks on icons). But I should be able to work around that, conditional on whether single clicking is set in preferences.

In #99275#1393981, @JanErik wrote:
is there a chance, that this feature will be part of 3.3 ?

I think the diff is in a good place, and it is only ~100 line change. But that said, I have no power around here (can't merge), so the code will still need to be code-reviewed and merged by somebody else.

> In #99275#1393315, @Slowwkidd wrote: > I wanted to ask if this will be also shown as an operator in the Outliner keymap preferences, giving the user the possibility to e.g. change from dbl-click to single click? I'll see if I can figure this out. There is just 1 slight complication (with event filtering being necessary on the first click for CTRL/SHIFT clicks on icons). But I should be able to work around that, conditional on whether single clicking is set in preferences. > In #99275#1393981, @JanErik wrote: > is there a chance, that this feature will be part of 3.3 ? I think the diff is in a good place, and it is only ~100 line change. But that said, I have no power around here (can't merge), so the code will still need to be code-reviewed and merged by somebody else.

Paul Kotelevets commented

2022-07-23 15:03:58 +02:00

In #99275#1393315, @Slowwkidd wrote:
Even though I still think that selecting the hierarchy with just 1 click on the whole item (icon + name), and not just the icon would be even more intuitive

It is not clear how will you reorder/manupulate nested collections in the outliner if a single click selects a hierarchy rather than individual elements.

However, we also faced with singleclick demand during Collection Manager addon design.
I mean - the need for "quickly individually view the contents of collections, selecting them through with a single click to understand what is where in a scene", so we decided to
assign Ctrl+LMB action to non-chaining resetting collection selection for that purpose (when selection of a collection resets existing selection, selecting only items that belongs to the first level of a collection)
instead of additive that we decided to assign to Ctrl+Shift+LMB (when selection of a collection adds/removes collection's nesting elements to a selection similar to the way it is made there).

But CM is an addon and its collection list is separate to separate collection navigation mechanics from object/general navigation mechanics presented in the outliner, so it can afford such design flexibility...
Outliner is an outliner, and it is supposed to support outliner's functionality first.

> In #99275#1393315, @Slowwkidd wrote: > Even though I still think that selecting the hierarchy with just 1 click on the whole item (icon + name), and not just the icon would be even more intuitive It is not clear how will you reorder/manupulate nested collections in the outliner if a single click selects a hierarchy rather than individual elements. However, we also faced with singleclick demand during Collection Manager addon design. I mean - the need for "quickly individually view the contents of collections, selecting them through with a single click to understand what is where in a scene", so we decided to assign Ctrl+LMB action to non-chaining resetting collection selection for that purpose (when selection of a collection **resets** existing selection, selecting only items that belongs to the first level of a collection) instead of additive that we decided to assign to Ctrl+Shift+LMB (when selection of a collection **adds/removes** collection's nesting elements to a selection similar to the way it is made there). But CM is an addon and its collection list is separate to separate collection navigation mechanics from object/general navigation mechanics presented in the outliner, so it can afford such design flexibility... Outliner is an outliner, and it is supposed to support outliner's functionality first.

Julio Cargnin Pereira commented

2022-07-28 13:38:02 +02:00

Added subscriber: @CosmoMidias

Julio Cargnin Pereira commented

2022-07-28 13:38:02 +02:00

In #99275#1386518, @santbg wrote:

In #99275#1386460, @1D_Inc wrote:

In #99275#1386006, @santbg wrote:
You might consider that a single click on the icon selects everything in the Collection, and to deselect click on the empty space.
Unless there are any drawbacks it is more intuitive and has no hidden hacks or shortcuts.

Then you will select collection's content instead of collection in case of missclicking, for example, when you need to move collections in the outliner.
Doubleclick prevents from this, separating selecting collection from selecting its content during fast work.

On twitter I saw that they created a new operator, in which you can assign the shortcut you want.
I don't know if it's someone from here.
https://twitter.com/CosmoMidias/status/1544498062907047936?s=20&t=4RsDLCxjwwjmVQwWEeFX8g

Hello, @santbg! That was me experimenting with the bult-in operators trough the keymap. Turns out that you can customize a lot, listen to double clicks and also pre define some options for an operator when invoked. But here we see the developers actually implementing some of those quality of life improvement in a much more robust and complete way. Super happy to see it happening!

> In #99275#1386518, @santbg wrote: >> In #99275#1386460, @1D_Inc wrote: >>> In #99275#1386006, @santbg wrote: >>> You might consider that a single click on the icon selects everything in the Collection, and to deselect click on the empty space. >>> Unless there are any drawbacks it is more intuitive and has no hidden hacks or shortcuts. >> >> Then you will select collection's content instead of collection in case of missclicking, for example, when you need to move collections in the outliner. >> Doubleclick prevents from this, separating selecting collection from selecting its content during fast work. > > On twitter I saw that they created a new operator, in which you can assign the shortcut you want. > I don't know if it's someone from here. > https://twitter.com/CosmoMidias/status/1544498062907047936?s=20&t=4RsDLCxjwwjmVQwWEeFX8g Hello, @santbg! That was me experimenting with the bult-in operators trough the keymap. Turns out that you can customize a lot, listen to double clicks and also pre define some options for an operator when invoked. But here we see the developers actually implementing some of those quality of life improvement in a much more robust and complete way. Super happy to see it happening!

Julio Cargnin Pereira commented

2022-07-28 13:51:48 +02:00

Glad to see this taking shape! Thank you!

There is one little suggestion I'd like to request:
when extending the selection with SHIFT key could we have it implemented in a way that the last selected click make the target active instead of keeping the first as the active? I think this would be more consistent with other areas in Blender (set active on last click). What you guys think?

Glad to see this taking shape! Thank you! There is one little suggestion I'd like to request: when extending the selection with SHIFT key could we have it implemented in a way that the last selected click make the target active instead of keeping the first as the active? I think this would be more consistent with other areas in Blender (set active on last click). What you guys think?

Paul Kotelevets commented

2022-07-28 23:18:40 +02:00

In #99275#1396560, @CosmoMidias wrote:
Glad to see this taking shape! Thank you!

There is one little suggestion I'd like to request:
when extending the selection with SHIFT key could we have it implemented in a way that the last selected click make the target active instead of keeping the first as the active? I think this would be more consistent with other areas in Blender (set active on last click). What you guys think?

Sounds interesting, but what for you need the active in cases when you have range selection?

In #99275#1394448, @1D_Inc wrote:

In #99275#1393315, @Slowwkidd wrote:
Even though I still think that selecting the hierarchy with just 1 click on the whole item (icon + name), and not just the icon would be even more intuitive

It is not clear how will you reorder/manupulate nested collections in the outliner if a single click selects a hierarchy rather than individual elements.

It seems it already moves collections like that, so 1 click selection can be actually useful. For example, it will allow to check in the viewport what objects you operate with.

> In #99275#1396560, @CosmoMidias wrote: > Glad to see this taking shape! Thank you! > > There is one little suggestion I'd like to request: > when extending the selection with SHIFT key could we have it implemented in a way that the last selected click make the target active instead of keeping the first as the active? I think this would be more consistent with other areas in Blender (set active on last click). What you guys think? Sounds interesting, but what for you need the active in cases when you have range selection? > In #99275#1394448, @1D_Inc wrote: >> In #99275#1393315, @Slowwkidd wrote: >> Even though I still think that selecting the hierarchy with just 1 click on the whole item (icon + name), and not just the icon would be even more intuitive > > It is not clear how will you reorder/manupulate nested collections in the outliner if a single click selects a hierarchy rather than individual elements. It seems it already moves collections like that, so 1 click selection can be actually useful. For example, it will allow to check in the viewport what objects you operate with.

Santy Berrones commented

2022-07-28 23:55:19 +02:00

I was looking for reference on how other systems work and C4D works with 1 click to select everything in a hierarchy.
🫣 Don't judge me just looking for reference to clarify an idea.

I was looking for reference on how other systems work and C4D works with 1 click to select everything in a hierarchy. 🫣 Don't judge me just looking for reference to clarify an idea.

Julio Cargnin Pereira commented

2022-07-29 02:39:57 +02:00

Sounds interesting, but what for you need the active in cases when you have range selection?

The reason is we usually plan to perform other operations after a group of objects are selected. For example Linking the Materials from the active object or copying selected modifiers from the active.

Currently after a range selection, I have then to hold CTRL, to deselect the object I want to make active, keep holding CTRL them selecting it again. Now it’s active and now I can perform the next operator that takes in account the active selection.

Or I have to beforehand remember that the outliner does not work like the other areas of Blender an start from the object I want to be active. And I usually fail in remember that because the muscle memory comes stronger from 3D view object selection and edit mode.

I’m sorry if this falls out of the scope of this patch but at first I thought it could be requested here. Thanks for working on that. - J.

> Sounds interesting, but what for you need the active in cases when you have range selection? The reason is we usually plan to perform other operations after a group of objects are selected. For example Linking the Materials from the active object or copying selected modifiers from the active. Currently after a range selection, I have then to hold CTRL, to deselect the object I want to make active, keep holding CTRL them selecting it again. Now it’s active and now I can perform the next operator that takes in account the active selection. Or I have to beforehand remember that the outliner does not work like the other areas of Blender an start from the object I want to be active. And I usually fail in remember that because the muscle memory comes stronger from 3D view object selection and edit mode. I’m sorry if this falls out of the scope of this patch but at first I thought it could be requested here. Thanks for working on that. - J.

Paul Kotelevets commented

2022-07-29 03:33:32 +02:00

In #99275#1396722, @santbg wrote:
I was looking for reference on how other systems work and C4D works with 1 click to select everything in a hierarchy.
🫣 Don't judge me just looking for reference to clarify an idea.

The problem is that layers system in C4D is not cumulative.
In Blender if you will select a collection which contain object located in other collections as well, it is not very clean how to rearrange such collection keeping cumulative object's instances in their original places.
It can be tricky to solve and even solved can be mind messing.

In #99275#1396740, @CosmoMidias wrote:
Currently after a range selection, I have then to hold CTRL, to deselect the object I want to make active, keep holding CTRL them selecting it again. Now it’s active and now I can perform the next operator that takes in account the active selection.

It require a good luck to have an object that is needed to be active, placed in the beginning or in the end of a desired range.
Such case is not very common, don't you think?

Or I have to beforehand remember that the outliner does not work like the other areas of Blender an start from the object I want to be active.

There are two strategies in active object paradigm.

Picking selection one by one - in this case active is the last one.
Picking the active and expanding selection with non-picking selection type (box/lasso/select all/ etc) - in this case, the first one remains active.
I think, current outliner's solution represents the same mechanics - you can pick one by one (in this case active will be the last), and you can pick active and expand the selection (in this case the active remains first).
I also think that it has another useful aspect - you can pick active in the viewport, then locate it in the outliner with num. (which is quite common situation), and expand the selection with ctrl+shift, keeping active for the desired operation.

> In #99275#1396722, @santbg wrote: > I was looking for reference on how other systems work and C4D works with 1 click to select everything in a hierarchy. > 🫣 Don't judge me just looking for reference to clarify an idea. The problem is that layers system in C4D is not cumulative. In Blender if you will select a collection which contain object located in other collections as well, it is not very clean how to rearrange such collection keeping cumulative object's instances in their original places. It can be tricky to solve and even solved can be mind messing. > In #99275#1396740, @CosmoMidias wrote: > Currently after a range selection, I have then to hold CTRL, to deselect the object I want to make active, keep holding CTRL them selecting it again. Now it’s active and now I can perform the next operator that takes in account the active selection. It require a good luck to have an object that is needed to be active, placed in the beginning or in the end of a desired range. Such case is not very common, don't you think? > Or I have to beforehand remember that the outliner does not work like the other areas of Blender an start from the object I want to be active. There are two strategies in active object paradigm. - Picking selection one by one - in this case active is the last one. - Picking the active and expanding selection with non-picking selection type (box/lasso/select all/ etc) - in this case, the first one remains active. I think, current outliner's solution represents the same mechanics - you can pick one by one (in this case active will be the last), and you can pick active and expand the selection (in this case the active remains first). I also think that it has another useful aspect - you can pick active in the viewport, then locate it in the outliner with num. (which is quite common situation), and expand the selection with ctrl+shift, keeping active for the desired operation.

Julio Cargnin Pereira commented

2022-07-29 04:14:58 +02:00

Such case is not very common, don't you think?

I should spend some time playing with the outliner now in a different mindset/expectation and feel it working. I think your points make sense. ✨👌🏽

edit: I was wrong about that. Sorry for the inconvenience and thank you for the heads up.

> Such case is not very common, don't you think? I should spend some time playing with the outliner now in a different mindset/expectation and feel it working. I think your points make sense. ✨👌🏽 edit: I was wrong about that. Sorry for the inconvenience and thank you for the heads up.

slwk1d commented

2022-09-22 16:25:36 +02:00

Since we'll soon already enter bcon2, can we hope to see this beauty for 3.4?

M. Grady Saunders commented

2022-09-25 16:52:25 +02:00

In #99275#1421155, @Slowwkidd wrote:
Since we'll soon already enter bcon2, can we hope to see this beauty for 3.4?

Still not entirely sure how/when the development phases kick off, but I hope so. I went ahead and caught up the diff with master. After rebuilding, the behavior still works as shown in the videos. If there is anything else I can do, let me know.

> In #99275#1421155, @Slowwkidd wrote: > Since we'll soon already enter bcon2, can we hope to see this beauty for 3.4? Still not entirely sure how/when the development phases kick off, but I hope so. I went ahead and caught up the diff with master. After rebuilding, the behavior still works as shown in the videos. If there is anything else I can do, let me know.

Jan-Erik commented

2022-10-13 11:33:16 +02:00

Would be really great, if this feature would finally land in master

Nico Traber commented

2022-10-13 12:33:15 +02:00

Added subscriber: @Nico-Traber

M. Grady Saunders was assigned by Pratik Borhade

2023-01-02 11:52:00 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Outliner: Double click on icon to select contents/hierachy #99275