Change Details

NOTE: This task does **not** cover the search menu of the data-block selector. There were ideas for this in the past, but they are not covered here. ## Motivation This initially was motivated by the addition of library overrides. Data-block selectors need a way to show library override operations. There are a few other issues the following proposal addresses: * **Scalability**: The current solution of adding little icon buttons next to the data-block name field doesn't scale well. It only works if there's a small number of operations. We need to be able to place more items for better data-block management. Especially with the introduction of library overrides. * **Discoverability**: It's not obvious what some of the icons do. They appear and disappear, but it's not clear why some are available at times and others not. * **Unclear Status**: Currently their library status (linked, indirectly linked, broken link, library override) isn't really clear. * **Unusual behavior**: Some of the icon buttons allow Shift or Ctrl clicking to invoke alternative behaviors. This is not a usual pattern in Blender. {F8796937} {F8796933} //Examples There is a conflict here: Many of the data-block selectors have little space, but users want to see many things at once: Fake user status, user count, name with sufficient space for long ones, often used operations (duplicate, unlink), etc. And there needs to be access to a data-block search box and advanced operations. ## Proposal [TODO properly explain this] {F9577242} {F9577245} {F9577247} #### Operations Menu #### Remaining Issues * Space is still an issue. The proposed design may be an improvement in some regards, but only slightly reduces needed space. * For now, this design won't display the library status icon (linked, indirectly linked, broken link, overridden, is-asset). There is just too little space for this. What other ways could we communicate this? ## Higher Level Issues There are at least two higher level issues, which are not addressed in this proposal, but can be addressed in a more or less orthogonal way: * Fake user is an ancient concept that should probably go (see T61209). Once that is done we don't need to show the fake user status icon. Maybe we can show the library status icon instead then. * Data-block selector is "abused" for general data-block management, because there is no proper place for that. E.g. the data-block could visualize the data-block relations (e.g. see <2.5 OOPS schematic) and provide better tools for managing them. A data-block selector should really just be used for managing a simple data-block user.

NOTE: This task does **not** cover the search menu of the data-block selector. There were ideas for this in the past, but they are not covered here. ## Motivation This initially was motivated by the addition of library overrides. Data-block selectors need a way to show library override operations. There are a few other issues the following proposal addresses: * **Scalability**: The current solution of adding little icon buttons next to the data-block name field doesn't scale well. It only works if there's a small number of operations. We need to be able to place more items for better data-block management. Especially with the introduction of library overrides. * **Discoverability**: It's not obvious what some of the icons do. They appear and disappear, but it's not clear why some are available at times and others not. * **Unclear Status**: Currently their library status (linked, indirectly linked, broken link, library override) isn't really clear. * **Unusual behavior**: Some of the icon buttons allow Shift or Ctrl clicking to invoke alternative behaviors. This is not a usual pattern in Blender. * **Misleading/incorrect terms and icons**: The current design mixes "Duplicate" and "New", as well as "Delete" and "Unlink". So it's unclear what a click on the duplicate-icon does for example. There is a conflict here: Many of the data-block selectors have little space, but users want to see many things at once: Fake user status, user count, name with sufficient space for long ones, often used operations (duplicate, unlink), etc. And there needs to be access to a data-block search box and advanced operations. ## Proposal [TODO properly explain this] {F9577242} {F9577245} {F9577247} #### Operations Menu #### Necessary Changes #### Remaining Issues * Space is still an issue. The proposed design may be an improvement in some regards, but only slightly reduces needed space. * For now, this design won't display the library status icon (linked, indirectly linked, broken link, overridden, is-asset). There is just too little space for this. What other ways could we communicate this? ## Higher Level Issues There are at least two higher level issues, which are not addressed in this proposal, but can be addressed in a more or less orthogonal way: * Fake user is an ancient concept that should probably go (see T61209). Once that is done we don't need to show the fake user status icon. Maybe we can show the library status icon instead then. * Data-block selector is "abused" for general data-block management, because there is no proper place for that. E.g. the data-block could visualize the data-block relations (e.g. see <2.5 OOPS schematic) and provide better tools for managing them. A data-block selector should really just be used for managing a simple data-block user.

NOTE: This task does **not** cover the search menu of the data-block selector. There were ideas for this in the past, but they are not covered here. ## Motivation This initially was motivated by the addition of library overrides. Data-block selectors need a way to show library override operations. There are a few other issues the following proposal addresses: * **Scalability**: The current solution of adding little icon buttons next to the data-block name field doesn't scale well. It only works if there's a small number of operations. We need to be able to place more items for better data-block management. Especially with the introduction of library overrides. * **Discoverability**: It's not obvious what some of the icons do. They appear and disappear, but it's not clear why some are available at times and others not. * **Unclear Status**: Currently their library status (linked, indirectly linked, broken link, library override) isn't really clear. * **Unusual behavior**: Some of the icon buttons allow Shift or Ctrl clicking to invoke alternative behaviors. This is not a usual pattern in Blender. * **Misleading/incorrect terms and icons**: The current design mixes "Duplicate" and "New", as well as "Delete" and "Unlink". So it's unclear what a click on the duplicate-icon does for example. {F8796937} {F8796933} //Examples There is a conflict here: Many of the data-block selectors have little space, but users want to see many things at once: Fake user status, user count, name with sufficient space for long ones, often used operations (duplicate, unlink), etc. And there needs to be access to a data-block search box and advanced operations. ## Proposal [TODO properly explain this] {F9577242} {F9577245} {F9577247} #### Operations Menu #### Necessary Changes #### Remaining Issues * Space is still an issue. The proposed design may be an improvement in some regards, but only slightly reduces needed space. * For now, this design won't display the library status icon (linked, indirectly linked, broken link, overridden, is-asset). There is just too little space for this. What other ways could we communicate this? ## Higher Level Issues There are at least two higher level issues, which are not addressed in this proposal, but can be addressed in a more or less orthogonal way: * Fake user is an ancient concept that should probably go (see T61209). Once that is done we don't need to show the fake user status icon. Maybe we can show the library status icon instead then. * Data-block selector is "abused" for general data-block management, because there is no proper place for that. E.g. the data-block could visualize the data-block relations (e.g. see <2.5 OOPS schematic) and provide better tools for managing them. A data-block selector should really just be used for managing a simple data-block user.