Overall this is a great change! Just a few pieces of feedback.

I would make the keymap explicit so we don't end up with this:

Right clicking on an object should expose this enum too, right?

Also changes the operator to create the new collection inside the active
collection rather than inside of the selected collection.

I'm not sure about this change personally, but I would be interested to see how others felt about it.
I guess it's nice to use the concept of the active collection more since we have it, but it's a pretty hidden
feature, and to me it feels much more intuitive / expected to have the new collection placed at the current
location in the tree. Especially when you're quite a few levels deep and the active collection is elsewhere.

In D8648#211104, @Hans Goudey (HooglyBoogly) wrote:

Also changes the operator to create the new collection inside the active
collection rather than inside of the selected collection.

I'm not sure about this change personally, but I would be interested to see how others felt about it.
I guess it's nice to use the concept of the active collection more since we have it, but it's a pretty hidden
feature, and to me it feels much more intuitive / expected to have the new collection placed at the current
location in the tree. Especially when you're quite a few levels deep and the active collection is elsewhere.

I can see arguments here for both sides. The reasoning behind using the active collection is that we already create new objects inside the active collection, regardless of how nested in the outliner it is. It is also very explicit and intentional which collection will be the parent of the new collection.

As an alternative, it's harder to define "current location in the tree". This could be the outliner active element's level, or we could find the level of the first selected object, or the selected collection as it was previously. I can think of cases though that could be as confusing as a deeply nested active collection. I'm also curious on other's thoughts.

You're right, "type" isn't clear. Instead of "mode" i used "method" since I think it's even more clear, and I also renamed the enum entries.

Good point, I didn't consider that the selected object could come from all over the tree. In that case using the
active collection is probably the most consistent.

There are plenty of opportunities to make "smart" behavior here, although we don't always want that.
For example, if all objects are just part of the same collection, make the new collection a child of the existing one.
Or always set the active collection to an object's parent collection when you select the object in the outliner.
These are probably beyond the scope of this patch though.

Or always set the active collection to an object's parent collection when you select the object in the outliner.

The active collection already jumps around a lot, making it hard to know which collection objects will be created in. I'm unsure whether this would help or exacerbate the problem, but it should be carefully evaluated before adding this behavior.

In D8648#211344, @Hans Goudey (HooglyBoogly) wrote:

Good point, I didn't consider that the selected object could come from all over the tree. In that case using the active collection is probably the most consistent.

I think for now it's best to stay consistent with adding new objects.

In D8648#211452, @Ryan Inch (Imaginer) wrote:

The active collection already jumps around a lot... I'm unsure whether this would help or exacerbate the problem, but it should be carefully evaluated before adding this behavior.

I agree that it would be great to find a more reliable method of adding objects/collections, but that would be for a separate patch.

Code looks good, but I see design topics to discuss. So same old story :) ... :/

• Changing the default behavior to move selected object to the new collection is a muscle breaking change. I'm unsure what people would expect. But we could easily change back to the old default, so we could just commit the change and see how people react.
• In the factory startup scene, activate the scene collection, create a new collection, select the collection, then select some objects and create a new collection. That demonstrates a behavior that people will run into often I think. And what it does appears quite odd and unexpected to me. I would expect the new collection to be created where the objects I selected were. So maybe it's indeed more reliable to ensure the active selection is always the one containing the active object (of course there's the corner-case of having an object linked into multiple collections...).
• In the factory startup scene, just adding a new collection used to add it to the scene collection. Now it's nested into the "Collection" one. Maybe we should change the default active collection to be the scene one.

At this point it would be really good to get a stakeholder artist to work with. Somebody who uses the Outliner a lot in a production environment. It's important that we improve things for these artists and don't slow them down.

Please make sure there's a clear rationale mentioned in the commit message. Why are these options useful? What does it improve? Even if the answers appear obvious.
Also please list all changes in the release notes. rB2c34e09b08fb needs to be added too.

In D8648#212796, @Julian Eisel (Severin) wrote:

• Changing the default behavior to move selected object to the new collection is a muscle breaking change. I'm unsure what people would expect. But we could easily change back to the old default, so we could just commit the change and see how people react.
• In the factory startup scene, activate the scene collection, create a new collection, select the collection, then select some objects and create a new collection. That demonstrates a behavior that people will run into often I think. And what it does appears quite odd and unexpected to me. I would expect the new collection to be created where the objects I selected were. So maybe it's indeed more reliable to ensure the active selection is always the one containing the active object (of course there's the corner-case of having an object linked into multiple collections...).
• In the factory startup scene, just adding a new collection used to add it to the scene collection. Now it's nested into the "Collection" one. Maybe we should change the default active collection to be the scene one.

The original implementation of this feature earlier in the summer behaved differently. The context menu and C shortcut key used the default behavior of empty new collections, and the header operator button was the only way to view the move/link options. I would prefer that behavior, but there were a few strong opinions devtalk (my only user feedback) that convinced me to make moving the selection the default behavior.

I'm willing to try creating the new collection at the level of the active element.

At this point it would be really good to get a stakeholder artist to work with. Somebody who uses the Outliner a lot in a production environment. It's important that we improve things for these artists and don't slow them down.

This would be fantastic. I imagine this would be something similar to the grease pencil team?

Please make sure there's a clear rationale mentioned in the commit message. Why are these options useful? What does it improve? Even if the answers appear obvious.
Also please list all changes in the release notes. rB2c34e09b08fb needs to be added too.

Will do :)

In D8648#212796, @Julian Eisel (Severin) wrote:

At this point it would be really good to get a stakeholder artist to work with. Somebody who uses the Outliner a lot in a production environment.

I think @Paul Kotelevets (1D_Inc) would be a good candidate for this.

Hello, everyone. Trying to analyse the concept.
Lets us see if I can be useful here.

Change the New Collection operator to have multiple options for
creating a new collection:

Empty
Move objects
Link objects

A very interesting concept, that will allow to organize scene faster.
I can see why it is limited only to objects processing - because, in the case of support for moving collections as well, a new collection, where it is possible to move the selected collections, can only be placed in Scene Collection or "instead of active collection".
Overall, being able to pack the entire selection of the outliner into a new collection looks appealing, but such functionality better fits to a separate function, that would require a more complex design.

Also changes the operator to create the new collection inside the active collection rather than inside of the selected collection.

In D8648#212796, @Julian Eisel (Severin) wrote:

• In the factory startup scene, activate the scene collection, create a new collection, select the collection, then select some objects and create a new collection. That demonstrates a behavior that people will run into often I think. And what it does appears quite odd and unexpected to me. I would expect the new collection to be created where the objects I selected were. So maybe it's indeed more reliable to ensure the active selection is always the one containing the active object (of course there's the corner-case of having an object linked into multiple collections...).

I think that terms "active collection" and "selected collection" should be clarified in the description, because this information cannot be obtained from the interface, so they can be interpreted in different ways.
Active collection is shown in text info and scene statistics and selected collections which are selected (or which objects are selected) in the outliner, hence the only collection selected is active. Is it correct?
If this is the case, then only the active collection can be clearly defined, and there are no other options.

It will require defining active collection after objects selection - additional action via Ctrl+LMB, but other options would make the destination unclear,
so the value of an active collection solution grows with the complexity of the scene - it is not that intuitive/useful for simple scene setups, but simple setups never cause problems by their nature.
Active object solution indeed have plenty of collection definition issues like absence of the active object in the selection if it was deleted, finding the collection containing the active object in long lists and active object linked to multiple collections.

In D8648#212796, @Julian Eisel (Severin) wrote:

• Changing the default behavior to move selected object to the new collection is a muscle breaking change. I'm unsure what people would expect. But we could easily change back to the old default, so we could just commit the change and see how people react.

I would like to say that it is not a muscle breaking change - the process of setting up a scene always requires the activity of the brain, and not the spinal cord, as, for example, using shortcuts in modeling.
(All the skills are knowledges that was compressed from the "brain" to "spinal cord" during repetitive training to take less memory/energy during use)

So the question is - is it worth getting used to the behavior that this concept suggests?
Along with the ability to quickly pack selected objects to a new collection this concept is about to propose a law "every new collection will be created in the active one", and this is a simple law that is easy to share, remember, keep in mind and use in scenes of any complexity.
The Active collection is the only collection that can be accurately defined and identified in the middle of the hierarchy, its name is shown in stats, and that kind of determination will be very useful for complex scenes, so in my opinion it is a fair trade-off.
If to make creating empty collection action follow this law, then there will be no exceptions, and the system will be completely natural.

In D8648#212796, @Julian Eisel (Severin) wrote:

• In the factory startup scene, just adding a new collection used to add it to the scene collection. Now it's nested into the "Collection" one. Maybe we should change the default active collection to be the scene one.

Indeed, that would be nice. This way adding a new collection will create linear collections structure instead of nesting, that is more useful for working from scratch.

That's my thoughts about topic, thank you for your attention.

By the way, new objects are created in the active collection, so this behaviour is already familiar to users.
So, the law that is proposed in this concept is, in fact, a unifying law - "All new objects and collections in Blender will be created in the active collection", making creation substances process and result predictable.

Thanks for taking a look. I'll get those points addressed later today.

In D8648#216613, @Julian Eisel (Severin) wrote:

• Make Scene Collection active by default in the startup.blend (so creating a new collection behaves like before after startup)

I believe I just addressed this. All I had to do was modify the startup.blend, right?

Also, changing the default collection will change the collection new objects are created in. New objects will be created in the Scene Collection by default now. Maybe that is different enough that it is okay to leave the default scene as-is?

• Right-clicking a collection should make it active. Otherwise the context menu may act on the wrong collection. -- I guess this is addressed with D8647 though?

That is addressed with D8647. Agreed that it should either be activated on right click in this patch, or this patch should go in after D8647 is committed.

• The icon button currently does whatever operation you used last via the context menu. So by default it's "Move Objects", after using context menu > "Link Objects", the icon also uses "Link Objects". Think that's a bug? It's weird and we don't think it should do this.

Definitely a bug. I must have removed something in the header drawing code. Fixed now.

New objects will be created in the Scene Collection by default now.

The Scene Collection is limited in functionality compared to regular collections and so doesn't have the organizational ability that regular collections have.
I think of the Scene Collection as a fallback, so objects don't get lost when deleting collections, or as a special usecase when objects need to always be visible.
So having it as the default for where objects are created seems counter-productive (most of the time you'll end up moving them to other collections anyway),
plus the indication of the active collection is easy to miss. (And yes, I know that I can easily set the active collection to something else, but it's an extra step that
could easily be forgotten and then you have a whole bunch of objects to move)

Having the button (not the menu items) create siblings instead of children would preserve the previous behavior, but then you would be unable to add children with it, so both ways have tradeoffs.

the header icon button to create a new collection defaults to moving the selected objects into the new collection.

Having the button automatically add selected objects to the new collections seems weird to me. I think moving objects to the new collection should be something the user explicitly triggers and not the default.
I would expect that adding a new collection would give me an empty collection, unless I specify otherwise.

Also changes the operator to create the new collection inside the active collection rather than inside of the selected collection.

This is okay for when no collections are selected or maybe for when multiple collections are selected, but it feels really weird when I right click on a collection and add a new collection expecting it to be added as a child of that collection,
but it gets added as the child of the active collection (which could be scrolled out of view).
To be honest, the way this works in the 2.90 feels much more intuitive to me than how it's handled in this patch.
In 2.90 I know exactly where every collection will be created without any thought, but in the patch I have to find
or set the active collection before I can know where my collection will be created.
However, if you're creating collections from something outside the Outliner, like a hotkey or the header button (although I have no complaints with how the header button works in 2.90), then adding them to the active collection makes sense.

The options to automatically move or link objects when creating collections are nice, though, but they're sometimes hard to trigger because right clicking can end up deselecting your objects.

In D8648#216855, @Ryan Inch (Imaginer) wrote:

New objects will be created in the Scene Collection by default now.

The Scene Collection is limited in functionality compared to regular collections and so doesn't have the organizational ability that regular collections have.

I think Nathan was talking about changing default blend file to make Scene Collection active by default there, not about changing the way objects will be created in Blender.
Objects will be still created in the active collection, but in default blend file with cube active collection will be Scene Collection, not the Collection_1.
So in default blend file objects will be created in Scene Collection because it will be the active one.

the header icon button to create a new collection defaults to moving the selected objects into the new collection.

Having the button automatically add selected objects to the new collections seems weird to me. I think moving objects to the new collection should be something the user explicitly triggers and not the default.
I would expect that adding a new collection would give me an empty collection, unless I specify otherwise.

Fair enough.

Also changes the operator to create the new collection inside the active collection rather than inside of the selected collection.

To be honest, the way this works in the 2.90 feels much more intuitive to me than how it's handled in this patch.
In 2.90 I know exactly where every collection will be created without any thought, but in the patch I have to find
or set the active collection before I can know where my collection will be created.

To clarify: under 2.90 behavior do you mean creating collection in the active collection when it is selected, and creating them is Scene Collection when objects/no collections are selected?
By the way, where can I get a build with this patch?

In D8648#217027, @Paul Kotelevets (1D_Inc) wrote:

I think Nathan was talking about changing default blend file to make Scene Collection active by default there, not about changing the way objects will be created in Blender.
Objects will be still created in the active collection, but in default blend file with cube active collection will be Scene Collection, not the Collection_1.
So in default blend file objects will be created in Scene Collection because it will be the active one.

This is correct.

the header icon button to create a new collection defaults to moving the selected objects into the new collection.

Having the button automatically add selected objects to the new collections seems weird to me. I think moving objects to the new collection should be something the user explicitly triggers and not the default.
I would expect that adding a new collection would give me an empty collection, unless I specify otherwise.

I don't care much which is default with the header icon button. I think it would be nice to always show the popup of all three options from the icon, but if an empty collection by default is best, then sure.

To be honest, the way this works in the 2.90 feels much more intuitive to me than how it's handled in this patch.
In 2.90 I know exactly where every collection will be created without any thought, but in the patch I have to find
or set the active collection before I can know where my collection will be created

The problem with the 2.90 logic of adding a new collection under the selected collection is it becomes impossible to specify a collection and choose objects to be moved/linked to the new collection. Also, selecting a collection makes it active, so that part of the workflow shouldn't have changed at all.

By the way, where can I get a build with this patch?

There is no build at the moment. This branch https://blender.community/c/graphicall/Qmbbbc/ has an older implementation of this patch.

In D8648#217072, @Zachman wrote:

By the way, where can I get a build with this patch?

There is no build at the moment. This branch https://blender.community/c/graphicall/Qmbbbc/ has an older implementation of this patch.

Thank you. It is win64, so I will be able to check it later.
This functionality is interesting to me because it proposes unified behaviour for creating substances, and this behavior is clear (you can always detect the name of an active collection), so I see its potential for managing complex scenes (like scenes with 30k objects, 300 collections with 6 nesting levels), and complex selections across the entire outliner, so I want to try it in practice.
My guess is that at first this should seem a little awkward for simple scenes, but be super clear for complex scenes, so I want to make sure my assumptions are correct.

@Paul Kotelevets (1D_Inc)

I think Nathan was talking about changing default blend file to make Scene Collection active by default there, not about changing the way objects will be created in Blender.

Yes, I understood that. But it's easy to miss where the active collection is, especially if it was in a different place by default before, and so when starting a new project it would be easy to forget and add all your objects into the Scene Collection instead of Collection.
This would just be a minor annoyance, but still....

To clarify: under 2.90 behavior do you mean creating collection in the active collection when it is selected, and creating them is Scene Collection when objects/no collections are selected?

Yeah, basically. Also when multiple collections were selected it would pop up an error message and not allow a collection to be created, which I think is good and can help prevent mistakes.

@Zachman

I think it would be nice to always show the popup of all three options from the icon, but if an empty collection by default is best, then sure.

How about clicking gives you an empty collection and click and hold pops up a menu with the 3 options? https://docs.blender.org/api/2.90/bpy.types.UILayout.html#bpy.types.UILayout.UILayout.operator_menu_hold

The problem with the 2.90 logic of adding a new collection under the selected collection is it becomes impossible to specify a collection and choose objects to be moved/linked to the new collection.

You're right, this is a hard problem to solve. What about keeping the default of creating the collection under the selected collection when you right click on a collection, but when objects are selected and you right click on them to move/link them to a new collection (which seems to be the only way the objects will stay selected to be moved anyway) the collection is created under the active collection (it gets created under the active collection because you haven't specified a collection by right clicking on it, the same way it would logically work if it were called from a hotkey or another outside influence)

Since the indicator for the active collection is fairly subtle in most themes, I think always having it as the main instigator of where a collection will be created will lead to collections getting created in unexpected places and slow down the collection creation process.
This isn't to say that it should never be used to designate where collections should appear, just that it shouldn't designate it when right clicking on a collection.

Hopefully this all makes at least some sense, and thank you for your work on this.

I tested that build (with colored collections by the way)
Well, now I am in doubds as Imaginer.
Creating collection in active is nice, moving objects to the active collection is awesome, but together they indeed feel clunky.

The problem is that there are two different actions with different requirements mixed in - when you create empty collection, you want to specify its name and location.
When you moving objects - you want to set source and the target.
Mixing those processes into one function makes it pretty much distractive.

I would recomment to split this function to its atoms:

• *Create empty collection* (that will create collections in the active one)
• *Move/Link selection to the active collection* function.

This behavior will follow regular filesystem folders workflow - where creating a folder and moving/copying files to it are different functions that follows different goals.

That's my first thoughts about this concept after several tests.

The problem of moving/linking/creating substances (substances interaction design) is a single design problem that also contain this issue:
https://developer.blender.org/T79267
So when you creating objects, they are created in the active collection, collections creation depends on selection, dragging objects into collection ignores already linked placed there, so it is not "move objects to collection action", but "sometimes move objects depending on luck" action, and now this patch combines moving and linking objects with creating empty collection as an immediate subcollection of an active one.

It seems that no one has yet tried to create a unified convenient system of interaction of substances, and this may be the first step along the way.

@Paul Kotelevets (1D_Inc) @Ryan Inch (Imaginer) thank you for the input. I think as you have said, there are many areas in the outliner that could be made more consistent and intuitive.

I do think that the Move/Link selection to new collection behavior of this patch is useful. I had a few ideas on how it could be implemented, at least in an initial state.

• Revert the changes here for adding the new collection inside the active collection. This would do the selected collection behavior from before.
• Use ctrl+g and shift+g for move and link selection to new collection.
  • There is also the object.move_to_collection bound to ctrl+g in the industry compatible keymap that could be useful.

A separate design task could be made for defining the interaction in the outliner with active collections, selection, etc.

In D8648#220006, @Zachman wrote:

@Paul Kotelevets (1D_Inc) @Ryan Inch (Imaginer) thank you for the input. I think as you have said, there are many areas in the outliner that could be made more consistent and intuitive.

I do think that the Move/Link selection to new collection behavior of this patch is useful. I had a few ideas on how it could be implemented, at least in an initial state.

Yes, it is definitely useful, but the concept need some polishing. It is good, but not the best possible)

• Use ctrl+g and shift+g for move and link selection to new collection.

Ctrl+G is reserved for Common Groups realization.
List of treads about Common groups.

A separate design task could be made for defining the interaction in the outliner with active collections, selection, etc.

Yes, such infrastructure is important and requires separate design process and attention, to define problems to solve and critical use cases to satisfy.

In D8648#220006, @Zachman wrote:

@Paul Kotelevets (1D_Inc) @Ryan Inch (Imaginer) thank you for the input. I think as you have said, there are many areas in the outliner that could be made more consistent and intuitive.

Your welcome, and thank you for undertaking the often arduous process of development and improvement.

I do think that the Move/Link selection to new collection behavior of this patch is useful. I had a few ideas on how it could be implemented, at least in an initial state.
Revert the changes here for adding the new collection inside the active collection. This would do the selected collection behavior from before.

Yes, this sounds good. If possible, I think keeping the button would be a good idea, either as a button with a menu as I suggested or just triggering a menu like you suggested.

Use ctrl+g and shift+g for move and link selection to new collection.

Not sure about the hotkeys, but given that there was call for exactly this (and there are no signs of a Common Groups realization coming any time soon) I think those hotkeys could work. And hotkeys can always be changed in the future if needed.

A separate design task could be made for defining the interaction in the outliner with active collections, selection, etc.

This sounds like a good idea.

In D8648#220049, @Ryan Inch (Imaginer) wrote:

Not sure about the hotkeys, but given that there was call for exactly this (and there are no signs of a Common Groups realization coming any time soon) I think those hotkeys could work. And hotkeys can always be changed in the future if needed.

Common groups are in top 10 requested features.
Almost every other software use this shortcut for creating common groups, (even 2.79, despite the fact its grouping system is, actually, tagging system) it is strong and useful industry standard.
This is quite strange that it was not taken into account during 2.8 development.
A lot of people are praying for this feature finally to land, so reassigning its shortcuts back and forth may be not suitable solution.

Common groups are in top 10 requested features.
...
A lot of people are praying for this feature finally to land, so reassigning its shortcuts back and forth may be not suitable solution.

Yeah, I'd love to see Common Groups realized too, but I haven't seen any mention of it on any roadmaps, so I wouldn't expect it anytime soon. (Hopefully, I'm wrong about this)
I don't have a strong personal preference as to what hotkeys should be used for moving/linking objects to a new collection, but ctrl+g is already used for an arguably broken version of what's added in this patch so it's not exactly "reserved".
Since something is going to be bound to ctrl+g anyway, I think it would be better to have it trigger the new working version rather than the old broken one.
This is my thought process, but I'll accept whatever is decided.

In D8648#220136, @Ryan Inch (Imaginer) wrote:

but I haven't seen any mention of it on any roadmaps

It is not our problem, if roadmaps don't take into account users demands, that mean that roadmap have blind spaces, so it is a problem of a roadmaps.

I think it would be better to have it trigger the new working version rather than the old broken one.

I don't see any use of that.
When you creating new collection filled with objects, you are

1. Making selection of objects (long operation, navigating viewport)
2. Going to the outliner to specify the active collection with the latest ctrl+click (long operation, scrolling lists, searching names to be sure where your objects will go, and don't messup with the entire scene setup)
3. Perform creating collection (instant operation to run the function)

So I don't see any use of shortening of already short part of a process.
In short - assigning those shortcuts solves non-existing problem - saving subseconds of a second for the scene management operation (which are pretty much idle, and are not that repetitive in practice)
Please, correct me if I am wrong, and there are use cases when shortcut significantly solves something, that cannot be achieved with button menu here.

In D8648#220136, @Ryan Inch (Imaginer) wrote:

This is my thought process, but I'll accept whatever is decided.

Well, okay then, an important note:

I think that creating collection and moving objects to it is better solved in CM

• you just press "Create subcollection"
• for a selected Collection that can be properly marked without the ability to loose your objects selection.
• in a pure Collections list, where active collection is properly highlighted
• and then just press that box icon near created collection to send objects to it... and that's everything you need, actually)
• Just use Shift+LMB with box icon to link a selection to a multiple collections.
• Also, you can check if that collection fits your expectations via isolation on Shift+LMB on Exclude Checkbox (EC RTO) to be sure you are sending selected objects to a right place.

I find this approach more practical.
The only thing I would like to recommend to add to a CM is calling new created collections incrementally, to inherit its ancestor name, to make it fit filtering requirements.
Linking objects to collections is not such a frequent operation for scene organization, because as a result you have to deal with the cumulativeness of the collections, it is way better fits QCD requirements and terms of use.
If in some case I will need to link objects to some collection (for example, a single reference to multiple slots), I will number it and press V, Shift+Num to send a selection to it.
And also, cumulativity checking functions are proposed there, so you will be able to detect both cumulative objects and collections.

So, sorry, I don`t think I will use that new functionality anyway - CM already solves almost any step of it better even without using any kind of ctrl+G, shift+G, or even outliner.
It is nice to have something by default, but definitely not bounding Ctrl+G shortcut.

It is not our problem, if roadmaps don't take into account users demands, that mean that roadmap have blind spaces, so it is a problem of a roadmaps.

Yes, I agree it's not our problem. I mentioned it to explain why I don't think common groups will get added soon, and so, why I think replacing the hotkey is not a big problem.

Please, correct me if I am wrong, and there are use cases when shortcut significantly solves something, that cannot be achieved with button menu here.

The only use case I can think of where the shortcut would be faster is if you need to move/link lots of objects to new collections and don't care where the collections are added.
But I don't have any idea how often such a use case would come up or if it would even come up at all.

The only thing I would like to recommend to add to a CM is calling new created collections incrementally, to inherit its ancestor name, to make it fit filtering requirements.

Interesting idea. I'm guessing that would look like Ancestor Name->Ancestor Name.001->Ancestor Name.002, etc., but let's talk about this on the CM thread and not hijack @Zachman's thread. :)

So, sorry, I don`t think I will use that new functionality anyway - CM already solves almost any step of it better even without using any kind of ctrl+G, shift+G, or even outliner.

I'm not sure if I'll use the new functionality much either, but I think it's good for the outliner to have it.

It is nice to have something by default, but definitely not bounding Ctrl+G shortcut.

The thing is, there is already an operator bound to Ctrl+G that creates a new collection and links the selected objects to it.
However, in my opinion it's broken (it doesn't add the collection to the collection tree) and can cause confusion in your scene setup.
I would prefer to have one of @Zachman's new operators be bound to Ctrl+G, rather than the old broken one.
I also wouldn't mind if Ctrl+G was unbound, but I think that's less likely to happen.

In D8648#220481, @Ryan Inch (Imaginer) wrote:

The thing is, there is already an operator bound to Ctrl+G that creates a new collection and links the selected objects to it.
I would prefer to have one of @Nathan Houghton (nathan) Craddock (Zachman)'s new operators be bound to Ctrl+G, rather than the old broken one.

Aw, got it.
I spent a lot of efforts tracking Ctrl+G for a year, and groups was announced multiple times, but at the end we have broken functionality assigned to that shortcut instead of them.
And, for sure, it is still impossible to distinguish linked from unlinked collections, because they are still all dumped into a single unsorted list, that makes this feature cause more problems than it suppose to solve.
Damn... I just have no idea how things like this end up in the master.
I guess that anything will be better than... that, so why not.

let's talk about this on the CM thread and not hijack @Zachman's thread. :)

Ok, sure.

I guess that anything will be better than... that, so why not.

That was my thinking.

In D8648#221624, @Pablo Vazquez (pablovazquez) wrote:

Definitely an improvement, especially now that the Scene Collection is active in new files, it doesn't break muscle memory.

In D8648#221748, @Zachman wrote:

So it's not a huge deal that objects added to scenes will now be added to the
scene collection by default with this patch applied?

I don't think changing the default active collection to the Scene Collection is a good idea. A common first action when starting a new project is to delete the default cube and add something else. If the default active collection is changed to the Scene Collection this will delete the cube from "Collection", but add the new object to the Scene Collection. and so your scene setup gets messed up. If you change the default active collection to the Scene Collection I think you should remove the default collection "Collection" and move all of it's objects to the Scene Collection.

I know that if you do mess up your setup this way it's easy to fix, but I think it's better not to introduce problems, no matter how small.

In D8648#221776, @Ryan Inch (Imaginer) wrote:

I know that if you do mess up your setup this way it's easy to fix, but I think it's better not to introduce problems, no matter how small.

Indeed. What about placing default objects to a Scene Collection and remove that Collection?
It is not necessary (like layer 0 in most programs), and always look like someone forgot it, so instead of just deleting cube to start work, you have to go to outliner and do something with that Collection, otherwise it will be forgotten and will go somewhere it should not be by accident, spreading through projects.

For example, when you appending collections to a new scene, to work with them separately, it is easy to forget that appended collections will go to that Collection instead of a Scene Collection.

In D8648#221781, @Paul Kotelevets (1D_Inc) wrote:

For example, when you appending collections to a new scene, to work with them separately, it is easy to forget that appended collections will go to that Collection instead of a Scene Collection.

Good point! I never thought about initially appending/linking collections. I'm starting to like the idea of discarding the initial Collection and having all objects reside in the Scene Collection by default more and more.
Also, depending on what you're doing, you may never need more than one collection i.e. the Scene Collection.

In D8648#228796, @Julian Eisel (Severin) wrote:

Actually I'm not too keen on merging this so late in bcon2. It messes with muscle memory quite a bit and we are not 100% certain about the trade-offs/implications.

I agree. And thanks, I'll get the startup file updated correctly