Also as a note, we could move the other available buttons to the menu. But I'm not too sure about that, since people may want quick access to operations like unlinking, making a single user copy, file opening or unpacking, etc. Also, the fake user button should probably be visible without having to go to the menu, to serve as a reminder.

So it's an option to move more operations to the menu, but I'm not sure about that. So leaving this as a possible future change on top of this.

I think there should be more operators in the menu. At least Delete (which is different than Unlink) and Reset Overrides. I'd even duplicate what's already available as dedicated buttons, to have a consistent and complete menu everywhere. If that menu has the icon + the name of the operation, it may also help users learn the meaning of the quick buttons.

For fake user, unpacking, we could consider moving them in the menu, but still showing the icon when they are enabled. That could be either a button, or a something more subtle in the text field right hand side.

This is more a topic for a design task though.

In D8554#208893, @Brecht Van Lommel (brecht) wrote:

I think there should be more operators in the menu. At least Delete (which is different than Unlink) and Reset Overrides. I'd even duplicate what's already available as dedicated buttons, to have a consistent and complete menu everywhere. If that menu has the icon + the name of the operation, it may also help users learn the meaning of the quick buttons.

Fully agree here.

Code-wise, I feel a bit sad that we have to keep the hackish template callback function instead of using proper operator buttons/menu entries, but this is a separate topic I think, so otherwise looks good to me.

Some notes:

• To better differentiate between duplicate and add, i added the "duplicate" operator as separate parameter to templateID. Most "_new" operators still mix logic on them, so it's hard to predict from the outside what they will do. I'd suggest splitting the operators as well, as I've already done to some operators in render_ops.c here.
• I added operators for unlinking and fake-user-toggling, so they can be used by superimposed icons.
• Changes done to superimposed icons should be committed separately.

I currently don't expect an in-depth review, but want to know if others approve this direction.

The direction seems good to me.

The only thing that's unclear to me is why both "Duplicate" and "Make Single User Copy" are needed. Don't they do the same thing?

Or maybe make single user is the default implementation of "Duplicate", and then you can override that with a duplicate operator where needed?

In D8554#220596, @Brecht Van Lommel (brecht) wrote:

The only thing that's unclear to me is why both "Duplicate" and "Make Single User Copy" are needed. Don't they do the same thing?

Yeah, it's a bit odd. It calls id_single_user() which does some special handling for grease pencil. The new/duplicate operators may also have some special handling.
So I would say we can just remove "Make Single User" from templateID. It's also available in the Outliner for actions and worlds. Probably because the Outliner has no way to call the operators on specific data-blocks. So I would leave it there for now.

Generally fine with the new layout.

Regarding duplicate versus make single user, one key difference I could see ( don't think it's the case currently, at least not fully) would be that duplicate operation usually does deep-copy of several dependencies of the ID as well (also controlled by user preferences), while make single user should only do a copy of the ID, and nothing else?

Hi, nice to see this gets tackled.
One thing: in my humble opinion, it's very useful to have in quick sight the number of users of datablocks, particularly because Blender is ehm.. quite good at making unnecessary duplicates.
I mean: copy-pasting or appending objects from other .blends makes a lot of 'myNodegroup.001' '.002' etc. Same for materials and textures.
Having the ability to easily spot them is a good idea for me.
Here is my old attempt: https://blender.community/c/rightclickselect/Kkcbbc/

In D8554#229399, @Lsscpp (lsscpp) wrote:

it's very useful to have in quick sight the number of users of datablocks

Has this information been hidden? I can't check it at the moment.
If so, in a system like blender's with it's unique Data-block Usage and Fake Usage, it's indispensable to have such information easily viewable at a glance, to know how many Users are sharing the data-block or if "0" users are using it and it will be erased on reload.
With novice people already frequently losing images, materials and other information due to not understanding what "Users" is, to make it easier for them to accidentally lose more of them is certainly a step backwards.

I'd even say that data-blocks with 0 users should have it's name or the number "0" highlighted in red to notify users of it's potential deletion, so to increase the deletion awareness, instead of reducing it by hiding information.

Just as a quick update what I'm currently doing/planning:

• For now the user count and fake user icon will only be visible in the menu. I smell that we'll have to bring them back. But we can test this in practice first and then make a decision with some more feedback.
• I'll remove/disable "Make Single-User Copy" from templateID for now. We shouldn't have features where we are unsure about what it does and if it's useful even. We can still bring it back.
• I split the "new" operators acting on templateID (UI_context_active_but_prop_get_templateID()) into "new" and "duplicate", so the menu can nicely show both. The button only shows the duplicate one.

So basically I'll move this forward but we can still do tweaks after merging.

I think this is ready to go into master now. But I will create a feedback thread on devtalk and expect having to do further tweaks.

I have not reviewed the code, but from testing this looks good.

For now the user count and fake user icon will only be visible in the menu. I smell that we'll have to bring them back. But we can test this in practice first and then make a decision with some more feedback.

I suspect the same, we likely have to add them at as icon at least when there are > 2 users or fake user is enabled, but not necessarily always.

I also think using a different icon for delete and unlink is even more important now, that x inside the text box looks even more like a "clear text" rather than "delete", than when it was a separate button.

And am also fairly certain we need the user count back in the main UI one way or the other, not hidden in the menu. ;)

Does it really make sense to do datablock selector overhaul before asset manager is done? Asset manager should mainly be managing datablocks, because the one dropdown UI was never a good idea for complete datablock management. Proper asset manager will make it easier to organize, duplicate, delete and otherwise manage the datablocks, so what should remain of this UI element should be just a slot where datablocks are just assigned or removed from. The actual management of them should imho be the domain of asset manager.

I know whe shouldn't mention other software here, but since Epic was a provider of MegaGrant in support of Blender, I don't believe they will mind. So, Unreal Engine is a good reference. They have a content (asset) browser where all the assets are managed, and every applicable object has an asset slot, equivalent of datablock slot, where the assets (datablocks) get assigned to or removed from. This is so much easier to understand and manage. Especially for example for materials. Users can very easily manage both materials which are present in the scene and those which are not, but still stored within the file. This would in turn make the old fake user nonsense completely obsolete.

The point of fake user was simply to prevent garbage collection of unused datablocks such as materials and garbage collection of unused datablocks was a consequence of Blender not really having any clear and straightforward way of managing persistent datablocks present in the .blend file. But asset manager would address this, which should in turn deprecate the fake user concept, as manual management of unused datablocks and decision whether or not to keep them should be much easier to do with a proper asset manager, which should have functions to for example remove unused datablock within the context of asset manager selection, or folder, etc...

Other than fake user, it's just way simpler concept to be able to for example duplicate and assign materials without dependency of viewport object selection. For example, currently, if you have a .blend file where you have some materials but no objects with material slots, it's borderline impossible to even manage materials, such as duplicate or edit them, without having to create some temporary dummy object in the scene first.

This initiative feels quite short sighted, without much thought of a bigger picture of future development. What I am seeing here is just some UI sugar without any real UX improvements or additional functionality.

In D8554#247122, @Ludvik Koutny (rawalanche) wrote:

Proper asset manager will make it easier to organize, duplicate, delete and otherwise manage the datablocks, so what should remain of this UI element should be just a slot where datablocks are just assigned or removed from.

Asset manager is just an asset manager - it doesnot allow to control distribution over scene.

Unreal Engine is a good reference.

UE is designed to use ready-made assets, not create them. Its area of application is much narrower than that of a Blender, so UE management problems can be solved with asset manager solution.
Asset management is mostly suitable for clean, properly made assets, it cannot handle the mess of the creation process.

The point of fake user was simply to prevent garbage collection...

The fake user is part of the garbage collection mechanizm. Objects with null users should be flagged anyway to protect against the garbage collector. Thus, if there are no fake users, there will be no automatic garbage collection.
Having any clear and straightforward way of managing persistent datablocks is a separate (and important) data management design task, but it is independent from fake users/garbage collector concept realization.

Temporary dummy object in the scene first.
What I am seeing here is just some UI sugar without any real UX improvements or additional functionality.

This happens when there are no correctly identified problems, so decisions do not contain solutions.

For example, we made a tool that generates a material palette from scene materials or selected objects materials.
If a scene contains 300 materials (which is pretty average amount for architectural visualization), it creates 300 polygons palette object,
so we can control material appearance and distribution right in the 3D viewport, taking into account scene lighting setup, or copy it to a new scene by simply copying the palette object.

Simple and flexible solution that holds the load perfectly.
It's a tool designed to solve a problem - flexible material management in trashy archiviz scenes. Similar tasks takes an eternity to solve in max or maya.
I'm not sure if any "asset manager" can possibly replace this tool for us as well.