Page MenuHome

Layer Switching Shortcut Inconsistency
Open, NormalPublic

Description

There is some improvement concept for collections shortcuts.
Currently, 1234 buttons shows a collection, but sending objects requires name in menu (M - "Collection 1" - "Collection 3" for example)
That would be nice if moving to collection will also support their number.

For example, "5" button shows collection called "Lighting Collection", so pressing "M5" will send selected objects to it.


See: T55162#619317 - originally from @Paul Kotelevets (1D_Inc)

Details

Type
Design

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Thanks, that will make organization of complex scenes faster.

Note that numbers are automatically assigned here, a solution could be to move the top menu item to be the last item.

We _could_ always have an exception where menus can request to handle number keys separately but think this isn't a good idea since it makes otherwise matching menus behave differently.

Campbell Barton (campbellbarton) lowered the priority of this task from Normal to Needs Information from User.Feb 13 2019, 3:23 AM

Making as incomplete since the desired behavior still needs to be resolved.

I think the numbers for collections is a weak concept to begin with. When you have nesting and unlimited numbers of them, the 1-9 numbers don’t map logically very well.

I imagine we could make much more useful use of the number buttons for other things, like active tools or direct access to modes, or just free keys for user shortcuts.

That said, increased consistency is a good thing, so if we keep the numbers for Collections, then it should ideally work inside that menu too.

I think the numbers for collections is a weak concept to begin with. When you have nesting and unlimited numbers of them, the 1-9 numbers don’t map logically very well.

I agree, it will not map well to be easy and intuitive with potentially unlimited number of layers, and it is not predictable enough for frequent use.
Number buttons should probably be reserved for something that maps better to the limited (1 to 9) available keys like selection modes in Edit Mode.

I think the numbers for collections is a weak concept to begin with. When you have nesting and unlimited numbers of them, the 1-9 numbers don’t map logically very well.

We don't need to fit all collections, we need to fit all available numbers, and we need fast collection navigation at any cost, regardless of their count or consistency.
Numbers don't fit unlimited collection concept, it doesnot matter, so we are going not from it's consistency, but from functionality - ability to switch/isolate required number fast.

1-9 (+ alt) nums allows to switch fast 20 collections and this is enough for comfortable work.
If user will set more than basic 20 collections - he will be forced by his will to know their names in any way in order to work with them, this is his choise, so there is no unconsistency at all.
Otherwise, if to remove 1-9 nums from collections, user will be forced to know each name every time he work with them.

That means no way to fast preview, no way to localize, no way to sort scenes object, keeping outliner opened (still without ability to isolate collection), and all of this is truely PAINFUL.
It was already removed from edit mode, so ability of comfortable modeling of something tightly surrounded by objects (like restoration) has gone.

Removing 1-9 nums from collections is a Really Bad Idea.

Note that numbers are automatically assigned here, a solution could be to move the top menu item to be the last item.
We _could_ always have an exception where menus can request to handle number keys separately but think this isn't a good idea since it makes otherwise matching menus behave differently.

That easily can be explained by workflow.
We pressing "5" - we see objects, that are in this collection, like, for example, trees. Or lights. Or masking objects. Or some other context.
So, we want to send another objects there, by the same context. (By the way, names were given to collections to represent that context.)
We are unhiding everything, selecting what needs to be sent - and pressing "M5" to send object to that collection. Automatic numeration is also ok there.
Doing that we do not care about collection name, its hierarcial placement, outliner ufolding, menu searches, or other things that makes workflow slower and expensive.

We are doing thing that we truely want behind all that things - we are sending context to context.
But doing it clean and fast.
That's the goal of this proposal.

What's the use case for moving object to "Scene collection" root? As far as I can see that's not something one should be doing often, so maybe that option souldn't even in the M menu? I know that's a different discussión from the problem at hand here, but it would also solve it.

What's the use case for moving object to "Scene collection" root? As far as I can see that's not something one should be doing often, so maybe that option souldn't even in the M menu? I know that's a different discussión from the problem at hand here, but it would also solve it.

It is useful when you need to move some objects by context from any kind of collections to organize them in other way.
If there are some objects in scene collection left, that means that "you left some objects to sort when has gone home yesterday", and objects in scene collection are that objects.

At least, until there is no "M5" ability we are talking about.

Quoted Text At least, until there is no "M5" ability we are talking about.

Well, if "scene collection" was removed from the M menu then we would automatically get the "M5" ability. And moving to "Scene collection" could still be done from the outliner in the (I would expect) rare cases where it is needed.

The proposal is to get rid of using outliner/GUI at some possible point.
I would prefer to set scene collection to digit 1 (start collection numeration from it) to have ability view whole scene without higlighing everything with alt+H, that freezes computer on complex scenes with selection outlines.

Also scene collection is needed to hold imported objects.

And no, removing scene collection will not automatically bring M5 ability.

here is my post on devtalk related to this tread:

For now when you have Scene Collection at the beginning, digital buttons (0-9) are not corresponds with default names of collections and hotkeys to change layer in object mode. So it will be better if key 1 moves object in the Collection 1 instead master collection.
When in sub-menu, for Sub-Collections same practice. But if you don’t want to move object in sub-collection, press Enter, because you want to confirm moving object into this collection, not in sub-collection.
And about markers, that displays in what collection objects now. Orange circle indicates current collection, Orange circle inside gray indicates a collection within another one.

So Master Collection can be assign to Enter instead of 1, with same logic as in submenu.

here is my post on devtalk related to this tread:

Not exactly, but better than nothing.

So Master Collection can be assign to Enter instead of 1, with same logic as in submenu.

Well, placing it to 1 will bring ability to view entire scene without unhiding and outlines)
It worth assigning "1" button.

Also, it may be possible to make it toggle in "entire scene" - "previously isolated collection setup" way, that is, actually, very handy.

Want to clarify issue about nums. First of all, it is a separate system.
A quick content displaying system (further - QCD) - part of verical (hierarcial) navigation, alongside with Outliner and RenderLayers.
There are workflows that depends on it, because it makes them possible, independently of layers, collections, selection groups, or any other hierarcial units and their number.
It is a unique system in the software industry, that makes Blender out of the ordinary. It's demand depends on the industry to which the workflow of user belongs.

You don't need QCD if you are in

  • Interior visualization (simple scene structure - walls, lights, cameras, furniture)
  • Exterior visualization (pretty much open spaces in scene's geometry)

You need QCD in industry, that requires close components placement with variations, such as

  • Engineering (complex scene structures with in place variations)
  • Historic restorations (Multirefrenced system with pointcloud and multiple images)
  • Game development / assets creation (LOD in place creation and comparison)
  • Medicine (prosthetics)

Some of that workflows requires QCD more than collections itself, that's why it is important.

Here is also Shift toggle inconsistency - Shift+numeral button doesnot toggles collection visibility.

For example, we starting from Collection 2 that containing object to render - pressing 2 to isolate it.
Then adding required collections with scene lighting/entourage objects to it, making them visible - pressing Shift+3, 4, 5, 6, 7... collections reveals
But if collection 7 contains obstacles, it cannot be hidden back with Shift+7, there is no way to hide it back with numeric buttons.

So, without Shift-toggling ability, the only way to get proper setup is to make all the same thing again, but remember that number 7 contains obstacles, and do not press it while Shift revealing nex time, keeping hope, that collections 8, 9 etc contains right objects, because if they don't, you will need to make it again and again.

You need to remember numbers instead of simple keypressing.

1-9 (+ alt) nums allows to switch fast 20 collections and this is enough for comfortable work.

I agree with that. Completely.
Usually in my worklow I use [1-5] &alt+[1-5] for collecting objects, armatures in main scene, and [6-0]&[alt 6-0] for assets to get quick access and show them up and hide by adding or excluding layers.
And when I need more complicated layers I just create a new scene in the same .blend file to keep things organized.

I agree that numbers for collections is a really weak concept. I think easy solution in this case is to make sure industry keymap is good enough so that most people will use it, and the people using legacy keymap, which will come with collection number hotkeys, will sooner or later switch to the industry one, once everyone else will be using anyway, and the legacy keymap will finally be deprecated.

For me manage collection with numbers is very important and make my work much faster. Also better is making all collection visible with one shortcut like in Blender 2.7x.

I think the easy solution, in this case, is to make sure industry keymap is good enough.

The problem is, the "INDUSTRY STANDARD" keymap never had things for quickly toggle layers. It's a unique Blender feature.

What's the point of making Blender follow the "INDUSTRY STANDARD", while the so-called "INDUSTRY STANDARD" is so far behind blender's innovation on the user interface. You know, the actual "USE" part.

Not to mention, also, as only a small part of the big industry, Blender is not here to change the industry standard. The industry standard is a thing everyone agrees on. Not something you can just change.

Some of these ideas, debates, and changes made to Blender's UI are so counter-intuitive/counter-productive it boggles my mind.

But for the actual topic, yea I think the Move to Collection key should work similarly like 2.7. OR,
what about moving the collection/layer control into a pie menu or something way more efficient than a bunch of keys in terms of efficiency? Such as an infinite scroll menu that corresponds to the number keys when open?

The reason I suggest an infinite scroll menu that responds to number key input only after the menu is open, is that I also don't like filling the 1-9 keys with almost identical functions only with parameter changes.

I was able to create menus in Blender where the operation works differently based on which modifier you held down when clicking the menu items.

So, we could go to this infinite scroll menu, find the collection you want to look at, click it, and show it; Shift-Click it to toggle its visibility; Alt-Click to move selection into this collection; Alt-Ctrl click to take the selection out of its original collection and put into the new collection.

Hell, we could even make this menu persistent after clicking, essentially making it a Collection/layer Manager.

The number 1 keys responds to the first displayed item in the list of collections, and scroll wheel scrolls the list.

I think the easy solution, in this case, is to make sure industry keymap is good enough.

The problem is, the "INDUSTRY STANDARD" keymap never had things for quickly toggle layers. It's a unique Blender feature.
What's the point of making Blender follow the "INDUSTRY STANDARD", while the so-called "INDUSTRY STANDARD" is so far behind blender's innovation on the user interface. You know, the actual "USE" part.
Not to mention, also, as only a small part of the big industry, Blender is not here to change the industry standard. The industry standard is a thing everyone agrees on. Not something you can just change.
Some of these ideas, debates, and changes made to Blender's UI are so counter-intuitive/counter-productive it boggles my mind.
But for the actual topic, yea I think the Move to Collection key should work similarly like 2.7. OR,
what about moving the collection/layer control into a pie menu or something way more efficient than a bunch of keys in terms of efficiency? Such as an infinite scroll menu that corresponds to the number keys when open?
The reason I suggest an infinite scroll menu that responds to number key input only after the menu is open, is that I also don't like filling the 1-9 keys with almost identical functions only with parameter changes.
I was able to create menus in Blender where the operation works differently based on which modifier you held down when clicking the menu items.
So, we could go to this infinite scroll menu, find the collection you want to look at, click it, and show it; Shift-Click it to toggle its visibility; Alt-Click to move selection into this collection; Alt-Ctrl click to take the selection out of its original collection and put into the new collection.
Hell, we could even make this menu persistent after clicking, essentially making it a Collection/layer Manager.
The number 1 keys responds to the first displayed item in the list of collections, and scroll wheel scrolls the list.

The industry keymap, which is already planned, will not be replacement for Blender's standard keymap. It will be shipped with Blender as an alternative. The reason you too will be using industry standard one is that after a few years, there will be almost no people left using Blender's legacy keymap ;)

The industry keymap, which is already planned, will not be replacement for Blender's standard keymap. It will be shipped with Blender as an alternative. The reason you too will be using industry standard one is that after a few years, there will be almost no people left using Blender's legacy keymap ;)

Remind me what I'm using in a few years. I never use default keymaps for any of my programs and I will never vouch for "INDUSTRY STANDARD" unless it is actually good.

Please stay on topic, alternative keymaps have nothing to do with this issue.

Found, that Shift+num toggling is workind in january build of 2.8
It has been broken recently

Bastien Montagne (mont29) raised the priority of this task from Needs Information from User to Normal.May 16 2019, 11:28 AM

Interestnig solution of Collection numeration from Dfelinto
https://wiki.blender.org/wiki/User:Dfelinto/Reports/2019#June_17_-_21

But the problem is that autonumeration is dynamic. That means, it requires more memory to remember which number belongs to which collection depending on current depth state. For example, if user want to send objects to Collection with number 5 via pressing M5, it is hard to say where objects will be sent.

So it will be better if first 20 slots, that available for numerals keypressing, will have static (adress) autonumeration independently of hierarchy depth, but with numeration starting from first level of hierarchy.

Static autonumeration is looking not so fancy as dynamic but is more usable.
Example - when scene's collections are formed, user can call collection as "1_Room", "2_Car", "3_Table" during single scene setup, and this numeration in static representation will be actual independently of depth parameter.

Here is numeration types comparizon
B2 type is the best one.

I've got a very clean allegory for everything happening around layers, that can explain a lot.

QCD (2.79 Layers) - is a navigational system. It's like a RAM.
It's only goal - to provide quick access to view and sort objects in a limited number of slots.

Collections - is a natural layer system.
It's like HDD - it allows to store a huge amount of stucturized data with low access speed.


The problem is that in Blender, the best RAM available on the market was replaced with a HDD instead of adding a HDD to the current RAM.


That's how this allegory looks like.

Probably a nonsensical suggestion, but...

It seems to me the central problem here is in how to auto-enumerate items in a hierarchical list, but one answer might be to NOT do so.

Why not instead treat this is an attribute of the collection instead: an optional secondary shortcut name? The first 9 collections created, no matter their relationship, simply get assigned shortcut names of "1" through "9". And you could choose to SEE them, drawn in a special way after the collection name in Outliner (off by default).

Afterward you might have many collections arranged in complex ways, but you could just manage the shortcuts if desired. Want to make the "Chairs" collection be number "4"? Just right-click on that collection and set it so.

In fact doing it this way would allow you to use all of "a-z" (and possibly A-Z) as well. So you might make "Chairs" be the "c" collection for a time and then later assign "c" to "Cars" just because it is easier to remember. Then you could move an object to the "Cars" collection by "mc", or hide "Cars" by Ctrl-h c"

Why not instead treat this is an attribute of the collection instead: an optional secondary shortcut name?

That actually makes a lot of sense. Explicitly mapping a collection to a number as a property of the collection itself.

I really dislike how numbers are not scalable and no longer map well to potentially unlimited layer. If this indeed opened up the possibility to map all other keys as well it will be extremely powerful while retaining speed

Great allegory!
The speed at 2.79 was that there was no need to look at the outliner and think. There was a clear system of squares always in sight)
An outliner is sometimes a heavy system.
If you compare the occupied space, then the layers in 2.79 are 1 part, and the outliner is 9 parts. Although the size is not important! )))

Probably a nonsensical suggestion, but...

I've already mapped all possible ways of autonumerating in my previous post in picture, including manual numeration, and marked their weak sides.
https://developer.blender.org/T61492#706904

Manually assigned numerations is easy to set, but have a lot of problems with handling and managing them.
It will require QCD 20 slots widget with object and availability marks.
Also it will be hard to locate 5 assigned slots in 1000 collection list.
Any type of autonumeration is devoid of these problems.

Alphabet has 28 symbols capacity (Capslock can bring a mess).
Also, goal of QCD not in wider range, but guarantee better control for strongly defined slots, including switching between and viewing them.

You can view 5 6 7 collection via pressing 5, Shift+6, Shift+7, but canot do that with alphabet, because it is mapped with blender shortcuts.

Yes, as far as I can tell, every way to auto enumerate is flawed and non-obvious.

Managing manual shortcut names does not have to be complex as the set is small and are identified with a single keystroke. The only important thing is there has to be a way of seeing them in the outliner when desired.

With manually-managed shortcut names there is no reason we couldn’t get our old 2.79 layer widget back. Optionally with 35 little buttons. Made a bit more useable since hovering would show both shortcut and the name of the collection.

Yes, as far as I can tell, every way to auto enumerate is flawed and non-obvious.

Of course it is, Collection system suddenly was designed without taking QCD into count. But if you can view through something fast, it solves problem.

Managing manual shortcut names does not have to be complex as the set is small and are identified with a single keystroke. The only important thing is there has to be a way of seeing them in the outliner when desired.
With manually-managed shortcut names there is no reason we couldn’t get our old 2.79 layer widget back. Optionally with 35 little buttons. Made a bit more useable since hovering would show both shortcut and the name of the collection.

That's complex management that is far away of QCD speed, as it available with Outliner simultaneously.
No remembering names, no setting attributes, no outliner modes switching, minimalistic interface - that's all brings insane amount of speed to QCD systems for viewing, managing, sorting, sending, comparing scene's content.

Just like RAM does.

@Paul Kotelevets (1D_Inc) : sorry, but I am unsure if your second paragraph is in agreement or disagreement with my comment you are quoting. There could be some words missing or “autocorrected” or perhaps I need more coffee. LOL.

Well)
I want to say it you have to hovering something, to see some name, that you need to remeber to invoke it then, it is already speed lost.
We are working with hundreds of scenes with millions imported objects from different sources to sort and compare.
On such a scale, remembering such local things that someone somewhere has somehow assigned is an overload of user's memory that we cannot afford.

Such system have to be predefined, and as simple as "hey, look at layer 3" or "compare 3 and 5" to allow us to survive.
And this is a serious UMC (User's Memory Consumption) problem.

Huh? I'm just not seeing that complaint.

You would yourself be assigning any shortcut 0-9, a-z to any collection you wanted. Faced with a UI element that had two rows of 5 I'm sure it would be obvious that these were for 0-9 and would be pretty quick to enable or disable the one you wanted.

If you wanted to (optionally) also show a second section containing a further 26 I think you could also quickly see which is which. What I was saying above is that, unlike in 2.79 these collections have names so you could see them when hovering over the little buttons.

Wow, a part of QCD widget!
Looking interesting)

I've seen a concept by Dobarro in twitter about growing widget, according to collections number, but it was looking too complex to use.
That realization is looking nice, I guess it can already help to sort content a lot.

I cant say if manual assignation is a good idea. It definitely have a potential, but we know theoretical problems it can cause, and only usability tests can give an answer how much usable it is.

... and my idea let’s you press “mc” to move an object to your “Cars” collection, “mh” to move to “Horses”. I don’t think you could get much more memorable than that.

... and my idea let’s you press “mc” to move an object to your “Cars” collection, “mh” to move to “Horses”. I don’t think you could get much more memorable than that.

that will definitely break nums compartibility, so there will no ability to compare slot 3 and 5, or set visible 2,3 6 and 9 slot simultaneously from keyboard quiclky.
Quick invoke - is a very important part of usability of such systems.

Here is an example of switching speed amount, that provides numeric input.
https://devtalk.blender.org/t/layers-maniphest/6578/32?u=1d_inc

Scull on this example is a pretty much cheating example - usually you have to compare same cars, or houses with some tiny changes, like window movements.

So they both will have almost same name, and only way to compare it - to press, for example, "1 2 1 2" buttons looking just on a model to figure out their differences.

Here is more precise example

As for making management simple I’d say it is by keeping it minimal. There are only 36 shortcuts, no attempt at adding more with sequences or modifier keys, just 0-9 and a-z. So close to, but still more than, our old 20.

And no complex maintenance of keys. You assign “4” to a collection and it happens immediately without confirmation, even if previously assigned. A collection that might have had that previously now has no shortcut. So effortless to change “c” from Cars to Chairs.

This just seems to get us the best of both worlds. We have an unlimited number of collections that can be organized in very complex ways. And we have a quick and simple method of getting to any arbitrary subset of 36 of them.

Well, then we still have problem to invoke and compare A and B slots, while numeric keys assignations are already saved for collections switching.
There is no basic need in 36 slots - in practice, if it isn't enough 20 slots for sort and cleanup , you are doing something wrong.
That's proven by decades of Blender using before 2.8

@Paul Kotelevets (1D_Inc) : that will definitely break nums compartibility, so there will no ability to compare slot 3 and 5

There's nothing in what I have said that should imply that. If you want to imagine having keys 0-9 assigned directly to the visibility of those collection shortcuts then so be it. That wasn't mentioned and doesn't affect the core idea. It just might be that what you want might only apply to the first 10, not to all 36, depending on how you want to set that up.

... but having the ability to show/hide a layer with a short command that ends in 0-9 or a-z is just a keymap issue.

But switching collections with 0-9 is already working, isn't it?
It is already mapped for 20 slots in 2.8 release
Only letter input can cause keymapping issues, so letter assignation is quite doubtable.

We never needed more than 20 slots to manage scenes all this years, so we, basically, so it is double doubtable from that point.

This thread is about which collections those apply to. You were bringing up keyboard switching.

Yikes. I'm out. The beautiful weather and my bike is calling. Laters.

Okay, I will write some thoughts to clarify whole problem. Cheers)

I want to say that QCD is a quick access system.
It is a solid system, that consists from:

  1. Limited slots for storing collections for quickest assignation and access.

There are 20 slots that already are assigned to 0-9 keymap, that allows to quickly

  • view single/multiple slots (manage their visibility)
  • send to slot (M5 problem)
  • filter/sort slot's content
  • compare slot's objects.

This amount of slots is enough for any kind of manual navigation/sorting/sending/viewing job, as far as it was enough for Blender since it began.
Adding letters support can increase amount of slots (capacity of system), but there is absolutely no need in it.

  1. Minimalistic GUI that allows to view/navigate empty slots.

GUI is needed to view what slots are currently turned on, that is especially useful when there are turned on several of them.

  1. Adressing slots to invoke them and send objects to them.

Currently, adress assignation is numeric automatic.


All this three parts combined makes proper QCD system.

Numeric input is good, as far as slots are numeric, that allows to slots to be anonymous, as far they are rewritable - any collection can be assigned to a slot.
It's capacity matches numeric keys already available and stored in keymap, so digits 0-9 and alt+0-9 are already managing slot's visibility.
A perfect solution.

Letters support can be also added, but it will definitely mess with current keymap and management.
Example - if to assign "Garments" collection to letter "G" it will not possible to get what slot it should to go and how to invoke it, because key "G" is already assigned for grab.
If to assign to "Garments" collection number 4 it is clear what slot it will take - 4th one, and you need to press 4 to invoke it.
Awesome and clean.

Adress assignation is automatic, that can require scene's collection order preparation.
I can’t say if this is bad, because collections can be dragged into the outliner.
Assignation of adress can be manual, but we don't know if it can casue management problems.
The only change I would like to make to this system - it to assign digit "1" to all collections in case of manual assignation, or assign digit "1" to Scene collection in case of autonumeration.

The problem is - it seems, there is no ability to view all collections via single hotkey.

I mean - at all. If you have 1000 of them, you are in trouble.
If all collections by default will be stored in slot "1" in toggle way, that will also bring clarity if there are collections in scene that do not belong to any other slots, with ability to view them.
Like ammo in an endless clip.


That will allow QCD system to handle and sort content of any amount of Collections.
Like RAM with HDD.

Also, if we are positioning QCD as collection's mess debugging tool, it may have a sense to make autonumbering for just first 20 core collections of first level, including scene collection as first, independently how deep collections will be inside of them.
It will be easy to hanlde them both in gui and outliner, and control them via dragging. This solution also helps to M5 problem.

So, that's how we've got B3 type of autonumeration, a slot numbering:

I still prefer A. The user gets to chose a subset that they feel is the most important, regardless of where the items exist in the list. Any auto assignment of slots will get increasingly bad as the list gets longer.

That's the problem - there are no more or less important collections.
Auto assignment also can't "get bad", it exist or not, as a rule. Rule is bad by default or good by defailt.

List will get longer in any case, but in autoassignation it is easy to tell where slots are - by opening outliner and, actually, looking on top of it. Tha't easy.

Manual assignation supposes that you are opening a scene with 1000 collections with 19 inlay amount of them - and go go search for them through entire outliner, if at least they are assigned, of course.
And, as practice shows, that will be funny only at first time...

QCD - is not a creative tool. Collections are.
QCD - is an emergency tool for Collections.
Something that can be definitely found in all this swamp of content, dumped by someone in hurry, that it supposed to manage with.

Maybe I'm not explaining it correctly, or I am misunderstanding something.

But auto-assignment, by definition, picks collections without your control. If you have a very small number of collections then all or most of them will be assigned. But once you have more collections than can be assigned then the remainder cannot be assigned. And it gets worse as the number of collections increases because the pool of unassigned collections increases. With manual assignment the user is always able to select what THEY think the most important collections are at any one time.

Again, unless I am missing something fundamental here. Which is certainly possible. LOL

If we need some specific collection, that is important - we will definitely knows it's name to have access.
Slots are aninymous structures, so it is more important where they are, than what they contain.

They should be static as dry land to swim to.
Otherwise, they will be like lifebuoy drowned with drowning in a Collection's ocean.

I can't imagine manually assigned 20 slots, that will not be immediately dissolved in 1000 collections file.
Then we will have 30 such files with random slots assignation, and that's it... a mess we were just starting from.

I'm still not quite understanding your concerns with this, so I am probably still missing something...

that will not be immediately dissolved in 1000 collections file.

You are using the thought of having 1000 collections and imagining some difficulty managing shortcuts, even though that management is not fleshed out. So imagining difficulty doing something hypothetical.

But with 1000 collections and automatically-assigned slots, wouldn't those slots simply point at (approximately) the first 20 collections always? And therefore render them useless since the chance of a slot containing something you want is only 2%.

So from my understanding of this, automatic assignment with 1000 collections is not useful at all, while manual assignment would work well, but there might be theoretical difficulty in the management of them?

If I am misunderstanding this please correct me because I would like to understand.

But with 1000 collections and automatically-assigned slots, wouldn't those slots simply point at (approximately) the first 20 collections always?

Yes it will.

And therefore render them useless since the chance of a slot containing something you want is only 2%.

No, it doesnot, as far as collections are draggable.

Collections are supposed to be used without QCD by developers by default.
But, if it is need in their reorganization, an emergency, they are dragged to QCD in order to be repaired. Like inventory.
So slots are filled with what is needed to be managed - when it's needed to be managed, or are filled with whatever, in case if there is nothing needed to be managed.
I save file, send to user, and he always know where to locate slots.

Also there is case for local scenes and some special type of work, like creating gamedev models with multiple LOD's, historic restoration with multiple refrences and so one, that requires static QCD more, than collections itself.
So autonumeration solution fits both worlds - it can be used as main engine for local work and as emergency for heavy scenes setup.

About manual numeration there is still an insoluble problem - 20 slots irrevocably dissolves in 1000 collections, and in 30 files it inevitably turns to mess.
For example, if to open someone's file, created with manual numeration, and press 2 to show slot 2- it is absolutely impossible to determine where belongs what it will show, and how to locate it in 1000 collections hierarchy.
Also it will be hard to reassing slot 2, because you will never know if it is assigned to something, and it's assignation is still needed, because it was assigned, for example, by other person.

It will take more time to locate and manage slots than to do actual work with them, so, manual assignation creates a logical mismatch at the level of building a workflow.

Thanks @Paul Kotelevets (1D_Inc),

Not trying to be obstinate for no reason, just trying to get to something that makes everyone happy.

So with a lot of collections auto-enumeration become useless unless you manually reorder the collections to suit the enumeration. So that is some manual work that we need to compare against the work of manually assignment.

Further, all of the numeration types you have outlined are (necessarily) complex because of collection hierarchy. For all these it would be difficult to drag folders to get a target number. In fact most dragging of a single item would renumber all those after it. That would not be fun.

Right-clicking on any folder within a list of 1000 and assigning it "9" from a popup menu is faster than dragging such a folder to the beginning of a list to a specific location in order for it to become "9". And then it would re-number all below it.

But I can certainly see your point that when sharing a large file you need to easily communicate what slot is for what collection. But with any scheme there needs to be a way to directly show these slot numbers. Otherwise, looking at your graphs there are many ways they could be enumerated and users would not be able to guess.

So if these slot numbers can be (optionally) shown in outliner, then it also makes sense that you can filter on only the collections that have such slot shortcuts. So regardless of scheme (manual or auto) you'd be able to quickly see slot assignments even in a very large list.

Not trying to be obstinate for no reason, just trying to get to something that makes everyone happy.

Okay. Indeed, there is a lot of things to think about.

So with a lot of collections auto-enumeration become useless unless you manually reorder the collections to suit the enumeration. So that is some manual work that we need to compare against the work of manually assignment.
Further, all of the numeration types you have outlined are (necessarily) complex because of collection hierarchy. For all these it would be difficult to drag folders to get a target number. In fact most dragging of a single item would renumber all those after it. That would not be fun.

Specific number doesnot matter for decades of layer using in Blender pre-2.8, so renumeration is ok.
You opening unfamiliar 2.79 scene and always checking it's layers first to get what is happening in scene.

Right-clicking on any folder within a list of 1000 and assigning it "9" from a popup menu is faster than dragging such a folder to the beginning of a list to a specific location in order for it to become "9". And then it would re-number all below it.
But I can certainly see your point that when sharing a large file you need to easily communicate what slot is for what collection. But with any scheme there needs to be a way to directly show these slot numbers. Otherwise, looking at your graphs there are many ways they could be enumerated and users would not be able to guess.
So if these slot numbers can be (optionally) shown in outliner, then it also makes sense that you can filter on only the collections that have such slot shortcuts. So regardless of scheme (manual or auto) you'd be able to quickly see slot assignments even in a very large list.

It is way faster to check 20 books on your shelf, than 20 bookmarks leaved somewhere in a library.
You can filter collections that have bookmarks, but locating them in entire hierarchy to define what it belongs to can take an eternity.
As it was described, easy to setup, hard to control.

I love idea of easy manual assignation, but I see frightening troubles that comes right after that, based on my experience, that can’t solve even in theory.

Currently Blender provides [B2] autonumeration. It is that is working now.
My proposal is [B3], that allows to view all slots at once in outliner in a plain way, also no outliner changes reqiured, so it can be build on it's current realization.
You prefer [A], that can reqiure massive outliner changes in order to make system clean enough. There will be a lot of things to do to ensure sufficient control, including additional modes, highlights, and filtering options.

Can't say if it's worth it.
Bookmark system feels like separate system.

A very nice example - photo dump sort and cleanup. A pretty much similar task.

Usually, some static folders are created in "SORTED" folder to move photos there to split them by their context.
Moreover, software such as Irfanview with F7/F8 keys allows you to send the photo you are viewing to one of 14 anonymous changeable folders, actually, a slots)
Like M5 shortcut action from topic.

That's incredibly handy solution, that allows to sort any amount of photoes. You can always see how much to sort is left - it's, actually, every photo beyond slots.
Unlike sending to folders, bookmarking photos strategy reaches its usability limit pretty much fast.

It seems, the only manageable system, based on bookmarking, is a single bookmark.
Easy to set, easy to find, easy to locate in hierarchy, easy to send objects to it.
That can work like a portal.
More bookmarks will inevitably mean the need for a system to organize such a system.

Hi, until now I never cared for shortcuts for collections because in blender 2.80 I didn't need them (not having projects of this size that required it ... but now I'm starting to go a little deep ... I had a sneak peek at this task but without really reading what was being discussed ... thinking that these shotcuts 1234567890 + shift had already been here and were working ... Today I was all happy to start doing in-depth tests .. going to also to review how the situation was in blender 2.7x , and all of a sudden I remembered how comfortable the layers were and how much in the past they helped me to organize the work visually and through shortcut ...

And now of all this, there is nothing left, my mouth has remained open and my eyes overflowed becoming aware that you had the courage to take everything away.

Guys, this was a blender killer features, one of the best, ok I perfectly agree that the collections extend endlessly the possibilities, but in practice, to have the shortcts for the first 10 positions, and to have a visual feedback of these, it was one of the best ideas Ton could have over 20 years ago ... so please...
Don't throw the baby out with the bathwater

A nice expression)

Well, there were a good reason, that explains QCD slots.
It is a tool, that effectively reduces UMC (User's memory consumption) in a wide range of workflows, and it has best realization in an entire industry.
There is also problem, that QCD doesnot works as a system with such kind of shuffilng.

I think we could take advantage of the tool system here. It's an easy way to dodge keymap conflicts and introduce niche operators without changing the learning curve. Add in a "Send To..." dialog that behaves similarly to the operator search dialog and you'd have a solid foundation for building new features.

Add in a "Send To..." dialog

It doesn't solve topic problem - ability to not only invoke, but also immediate sending to fixed number address.

However, I don't know how it is supposed to manage file wilth 1000 named collections list without such search dialog.
Nobody seems to have set such a task. You have 1000 names - you need a search menu to find collection or send selection - it is so obvious that it does not seem to have happened by chance.

The main problem of current collection development is that it follows a very strange way - like collections have limit in 20-30 of them.
We need to somehow convey the idea that it is already possible to make thousands of them, and all of this needs to be somehow managed.

Also, is seems, some steps have been taken in direction of M5 issue.
Now M5 shortcut can send object to somewhere (5th string in a menu), but pressing 5 will not show collection with that object, and you have to find it manually)

So, shortcut inconsistency issue seems to still remain...

Guys, I believe that we are really losing ourselves in a glass of water, because the two systems could really coexist, the "layer" system is a system of mere visual organization ... so it could also contain "VISUAL- 3D VIEW - ORGANIZATION more collections as well as objects "...
so in a sense, it is the 3D VIEW that contains VIEW LAYER, it has nothing to do with the Collections of object in itself ..

in this sense, it also becomes obvious, that every 3D View, can contain its local layout of VIEW levels ...

the outiliner and the collections have global value, so if you hide an object or a collection in the outliner, it's simple.... the object is hidden in all 3D View levels

in 3d view layers, objects can only be moved not hidden. when you select only one level, you are not hiding other objects, but you display everything that is only in that level view.

A very nice picture, that clarifies quick access slot concept.
It also depicts that QCD system can be built on top of collections system, bringing QCD's RAM speed access to Collection's HDD storage.
It also need wildcard match "Quick search" dialog to provide access to deeply located collections by their name.

kaiwas (kaiwas) added a comment.EditedMon, Aug 19, 5:05 PM

it would be great!
I have nothing to offer, but I agree that collections and “layers” can exist together.
That would be convenient.

Described overall problems of current realization and latest solutions in that post: https://developer.blender.org/D5118#127263