UI: Cleanup Dialog to Manage Orphaned Data #117242

Closed
Harley Acheson wants to merge 4 commits from Harley/blender:ManageData2 into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Member

Creates a new "Cleanup" dialog that allows purging unused data blocks,
as well as a window used for managing unused data blocks.


Whether or not we keep, change, or improve our practice of removing unused data-blocks, we need tools that allow users to more easily select what to keep and delete.

The File/Cleanup menu confusingly contains six items that all call the same operator in different ways. They each remove unused data but there is one for local only, linked only, and one where you have to assume does both. And for all three there is an alternative that adds the word "Recursive" without much explanation. The tooltip description for all six is identical: "Clear all orphaned data-blocks without any users from the file". Even this text is confusing as "orphans" have no parents, while these are just without owner.

Once you decide which of the six items to select, you are then presented with an ugly confirmation dialog:

1PurgeNow.gif

This patch replaces all six menu items with one item. And also adds a new item:

2image.png

"Purge Unused Data..." gives you a single dialog where you can delete any type of unused data, in a manner that I think is more informative:

3image.png

"Manage Unused Data..." brings up a window with Outliner in "Orphan Data" mode so that you can have more fine-grained control:

4ManageUnusedWindow.png

Unresolved Review Questions:

This is a recreation of a PR that is now closed, but can be found here.

Do not invoke modal UI items from an exec function. This code should be in the invoke callback.

Sorry about that. I swear I changed and tested that locally, but must have reverted or otherwise did something dumb that kept me from pushing that change. Now fixed.

Further more, any reasons not to use some operator-aware popup system, like WM_operator_props_dialog_popup or so?

Yes, that code does not offer the results and control I want here. I want a button to do the action, a button to cancel, and I want to show lists of items that would be cleared beforehand. This PR results in a dialog that matches the style of others in place and others that will be in place soon (#117153, #117152, #117151, #117154, #117155, #117156, #117157)

Another point I just realized: If you are renaming "orphan" to "unused", you should also tackle the other areas of the UI (starting with the name of the Outliner view itself).

We discussed this in the UI Module meeting and agreed this is not something to address here or yet.

Creates a new "Cleanup" dialog that allows purging unused data blocks, as well as a window used for managing unused data blocks. --- Whether or not we keep, change, or improve our practice of removing unused data-blocks, we need tools that allow users to more easily select what to keep and delete. The File/Cleanup menu confusingly contains six items that all call the same operator in different ways. They each remove unused data but there is one for local only, linked only, and one where you have to assume does both. And for all three there is an alternative that adds the word "Recursive" without much explanation. The tooltip description for all six is identical: "Clear all orphaned data-blocks without any users from the file". Even this text is confusing as "orphans" have no parents, while these are just without owner. Once you decide which of the six items to select, you are then presented with an ugly confirmation dialog: ![1PurgeNow.gif](/attachments/add118a5-50cc-431f-9a91-e6c853629139) This patch replaces all six menu items with one item. And also adds a new item: ![2image.png](/attachments/5d832bd3-7f32-4392-8789-dea8a8662034) "Purge Unused Data..." gives you a single dialog where you can delete any type of unused data, in a manner that I think is more informative: ![3image.png](/attachments/3973e631-eed2-4c1b-a0c3-3823dce781a4) "Manage Unused Data..." brings up a window with Outliner in "Orphan Data" mode so that you can have more fine-grained control: ![4ManageUnusedWindow.png](/attachments/406635b8-168e-49d9-a20e-6097f7522ba5) ### Unresolved Review Questions: This is a recreation of a PR that is now closed, but can be found [here](https://projects.blender.org/blender/blender/pulls/106653). > Do not invoke modal UI items from an exec function. This code should be in the invoke callback. Sorry about that. I swear I changed and tested that locally, but must have reverted or otherwise did something dumb that kept me from pushing that change. **Now fixed**. > Further more, any reasons not to use some operator-aware popup system, like WM_operator_props_dialog_popup or so? Yes, that code does not offer the results and control I want here. I want a button to do the action, a button to cancel, and I want to show lists of items that would be cleared beforehand. This PR results in a dialog that matches the style of others in place and others that will be in place soon (#117153, #117152, #117151, #117154, #117155, #117156, #117157) > Another point I just realized: If you are renaming "orphan" to "unused", you should also tackle the other areas of the UI (starting with the name of the Outliner view itself). We discussed this in the UI Module meeting and agreed this is not something to address here or yet.
Harley Acheson added 1 commit 2024-01-17 17:27:01 +01:00
5cbeb9f8c8 UI: Cleanup Dialog to Manage Orphaned Data
Creates a new "Cleanup" dialog that allows purging unused data blocks,
as well as a window used for managing unused data blocks.
Harley Acheson added this to the User Interface project 2024-01-17 17:27:31 +01:00
Harley Acheson requested review from Bastien Montagne 2024-01-17 17:27:39 +01:00
Member

It would be great to not have "Cancel" as the default action highlighted in blue.
While testing this PR today I kept noticing that I never actually purged any unused data :D

It would be great to not have "Cancel" as the default action highlighted in blue. While testing this PR today I kept noticing that I never actually purged any unused data :D
Harley Acheson added 1 commit 2024-01-17 17:50:36 +01:00
Author
Member

@JulienKaspar - It would be great to not have "Cancel" as the default action highlighted in blue.

I updated this PR to set the Delete button as default. I don't like the chance of destructive behavior from an accidental press of Enter, but this is a very explicit operator selection and these things are unused and would be removed.

> @JulienKaspar - It would be great to not have "Cancel" as the default action highlighted in blue. I updated this PR to set the Delete button as default. I don't like the chance of destructive behavior from an accidental press of Enter, but this is a very explicit operator selection and these things are unused and would be removed.
Harley Acheson added 2 commits 2024-01-17 18:59:39 +01:00
Author
Member

@mont29

Sorry about that. Until Julian pointed it out I didn't realize that I had not changed from exec to invoke, as you correctly pointed out in review. I swear I did make that change locally and tested it, but must have reverted or did some other dumb thing that kept that change from being pushed. Now fixed.

@mont29 Sorry about that. Until Julian pointed it out I didn't realize that I had not changed from exec to invoke, as you correctly pointed out in review. I swear I did make that change locally and tested it, but must have reverted or did some other dumb thing that kept that change from being pushed. Now fixed.
Contributor

On a small stylistic note, we might not want to capitalize all of the dialog's title words here. The "From This File" part is additional information compared to "Purge Unused Data" which is the original operator name, and should thus probably be emphasized to add contrast. This would thus give us "Purge Unused Data from this file".

On a small stylistic note, we might not want to capitalize all of the dialog's title words here. The "From This File" part is additional information compared to "Purge Unused Data" which is the original operator name, and should thus probably be emphasized to add contrast. This would thus give us "Purge Unused Data from this file".
Author
Member

On a small stylistic note, we might not want to capitalize all of the dialog's title words here. The "From This File" part is additional information compared to "Purge Unused Data" which is the original operator name, and should thus probably be emphasized to add contrast. This would thus give us "Purge Unused Data from this file".

Maybe. But there is an advantage of Title Case in that it is easily described and (fairly) unambiguous. As in we could just tell people to use title case for the title and sentence case for the body and that would work in most cases. Otherwise we can get weird holy wars where one person changes all the titles slightly then someone else changes them back. LOL

> On a small stylistic note, we might not want to capitalize all of the dialog's title words here. The "From This File" part is additional information compared to "Purge Unused Data" which is the original operator name, and should thus probably be emphasized to add contrast. This would thus give us "Purge Unused Data from this file". Maybe. But there is an advantage of Title Case in that it is easily described and (fairly) unambiguous. As in we could just tell people to use title case for the title and sentence case for the body and that would work in most cases. Otherwise we can get weird holy wars where one person changes all the titles slightly then someone else changes them back. LOL
First-time contributor

The "From This File" part is additional information compared to "Purge Unused Data" which is the original operator name

Grammatically, that's neither sentence case, nor title case. The fact that "Purge Unused Data" is the actual name of the operator seems incidental; what something is called in the code base shouldn't be the overall determining factor on if the menu item presents well.

The actual correct use of title case would be: Purge Unused Data from this File

But, I think Harley's point on potential grammatical holy wars is a fair one, so initial caps might be preferred. (As in the example, Purge Unused Data From This File)

>The "From This File" part is additional information compared to "Purge Unused Data" which is the original operator name Grammatically, that's neither sentence case, nor title case. The fact that "Purge Unused Data" is the actual name of the operator seems incidental; what something is called in the code base shouldn't be the overall determining factor on if the menu item presents well. The actual correct use of title case would be: _Purge Unused Data from this File_ But, I think Harley's point on potential grammatical holy wars is a fair one, so initial caps might be preferred. (As in the example, _Purge Unused Data From This File_)
Author
Member

The actual correct use of title case would be: Purge Unused Data from this File

I'm not seeing that variation in any style guide...

AMA: Purge Unused Data From This File
AP: Purge Unused Data From This File
APA: Purge Unused Data From This File
Bluebook: Purge Unused Data from This File
Chigago: Purge Unused Data from This File
MLA: Purge Unused Data from This File
NY Times" Purge Unused Data From This File

> The actual correct use of title case would be: _Purge Unused Data from this File_ I'm not seeing that variation in any style guide... AMA: Purge Unused Data From This File AP: Purge Unused Data From This File APA: Purge Unused Data From This File Bluebook: Purge Unused Data from This File Chigago: Purge Unused Data from This File MLA: Purge Unused Data from This File NY Times" Purge Unused Data From This File
First-time contributor

I'm not seeing that variation in any style guide...

The war has begun... ;)

Yeah, it's seriously going to be a stylistic thing. I have issues with AP style, and a fun thing with AMA - sometimes they even contradict themselves in odd ways. (I enjoyed a long battle of "healthcare" vs "health care" last year, that was fun...)

So, i think your original approach - just full initial caps - will be a good catch-all.

> I'm not seeing that variation in any style guide... The war has begun... ;) Yeah, it's seriously going to be a stylistic thing. I have issues with AP style, and a fun thing with AMA - sometimes they even contradict themselves in odd ways. (I enjoyed a long battle of "healthcare" vs "health care" last year, that was fun...) So, i think your original approach - just full initial caps - will be a good catch-all.

I'll split my input in several comments, to avoid a single monster post.

This feedback will be on a technical (code and architecture) level only.

The usability/UI/UX review has already been done and validated by the UI module. For what's worth, from an end-user perspective, I find the proposed changes in this PR to be a great improvement over current situation.

I'll split my input in several comments, to avoid a single monster post. This feedback will be on a technical (code and architecture) level only. The usability/UI/UX review has already been done and validated by the UI module. For what's worth, from an end-user perspective, I find the proposed changes in this PR to be a great improvement over current situation.

Here is some feedback on a fairly high, general level.

Further more, any reasons not to use some operator-aware popup system, like WM_operator_props_dialog_popup or so?

Yes, that code does not offer the results and control I want here. I want a button to do the action, a button to cancel and I want to show lists of items that would be cleared beforehand. This PR results in a dialog that matches the style of others in place and others that will be in place soon (#117153, #117152, #117151, #117154, #117155, #117156, #117157)

I don't think this is the right approach. If the results of a high-level API does not give satisfaction, then this API should be improved. The solution of going into lower level of code should only be considered in two cases:

  1. For rapid prototyping and feature/UI/UX design level review. A proper solution should then be implemented before the technical implementation review begins.
  2. In case the cost of modifying the existing API would be extremely high for the expected returns.

I am fairly certain we are not in situation 2. here. Situation 1. was OK to get the feature validated on a usability level, but it is now in a 'technical review before merging' state.

Here are the Pros I see to using/improving generic API vs. hacking specific solutions using low-level code:

  • Consistency: A similar behavior is ensured for all usecases. If some changes or improvements are needed, all existing use-cases benefit from it (and/or checking on the impact of the proposed changes on existing use cases can uncover unexpected side effects or issues).
  • Simplicity and Safety: Using an API already used in several other places avoids having to consider complex, maybe hidden aspects of the code.
  • Maintainability and Upgradeabilty: If fixes or improvements are needed, they can be done in a single place (implementation of the API), instead of having to chase down all potentially similar cases in custom code implementing (roughly) the same thing.

On a practical level, I think the only missing thing from WM_operator_props_dialog_popup is the dual Cancel/Validation buttons, with customizable labels? Currently, this API will generate a single 'validation' button, and cancel is done by clicking outside of the popup or hitting escape.

I believe that adding an explicit cancel button for all these operator-based pop-ups would be beneficial (easier for users who are not familiar with Blender UI history) and consistent with other types of popups. This is a separate design & PR topic for the UI module though.

Here is some feedback on a fairly high, general level. > > Further more, any reasons not to use some operator-aware popup system, like `WM_operator_props_dialog_popup` or so? > > Yes, that code does not offer the results and control I want here. I want a button to do the action, a button to cancel and I want to show lists of items that would be cleared beforehand. This PR results in a dialog that matches the style of others in place and others that will be in place soon (#117153, #117152, #117151, #117154, #117155, #117156, #117157) I don't think this is the right approach. If the results of a high-level API does not give satisfaction, then this API should be improved. The solution of going into lower level of code should only be considered in two cases: 1. For rapid prototyping and feature/UI/UX design level review. A proper solution should then be implemented _before_ the technical implementation review begins. 2. In case the cost of modifying the existing API would be extremely high for the expected returns. I am fairly certain we are not in situation 2. here. Situation 1. was OK to get the feature validated on a usability level, but it is now in a 'technical review before merging' state. Here are the Pros I see to using/improving generic API vs. hacking specific solutions using low-level code: * Consistency: A similar behavior is ensured for all usecases. If some changes or improvements are needed, all existing use-cases benefit from it (and/or checking on the impact of the proposed changes on existing use cases can uncover unexpected side effects or issues). * Simplicity and Safety: Using an API already used in several other places avoids having to consider complex, maybe hidden aspects of the code. * Maintainability and Upgradeabilty: If fixes or improvements are needed, they can be done in a single place (implementation of the API), instead of having to chase down all potentially similar cases in custom code implementing (roughly) the same thing. ---- On a practical level, I think the only missing thing from `WM_operator_props_dialog_popup` is the dual Cancel/Validation buttons, with customizable labels? Currently, this API will generate a single 'validation' button, and cancel is done by clicking outside of the popup or hitting escape. I believe that adding an explicit cancel button for all these operator-based pop-ups would be beneficial (easier for users who are not familiar with Blender UI history) and consistent with other types of popups. This is a separate design & PR topic for the UI module though.

Here is a summary of the high-level technical issues I have with the current code. I will ignore smaller issues for the time being.

From initial review of the old PR:

  • Adding a new operator (OUTLINER_OT_orphans_cleanup), which is essentially an empty shell only used to trigger the creation of the pop-up.
  • Using low-level pop-up creation code (UI_popup_block_invoke), with a custom UIButton callback (wm_block_orphans_purge), that essentially duplicates the same code in existing operator's exec function (outliner_orphans_purge_exec).

Re-using and improving the existing operator (OUTLINER_OT_orphans_purge) and using operator-popup API instead should be possible.

New issues identified while working again on that PR:

  • The undo stack is broken in current PR (it seems to create a new undo step everytime the user updates an operator setting, and no undo step for the actual deletion operation).
    This is a direct consequence of trying to by-pass the whole operator system and using 'raw' code like wm_block_orphans_purge.
  • The reported amount of IDs to be deleted is not always correct.
    The main reason is that there are inter-dependencies between the operator settings, e.g. local and recursive settings will affect the results for the linked data, etc.
  • The reported amount of IDs to be deleted does not update when settings change.
    This is also easily addressed when using the existing WM Operator/PopUp framework.

Issues identified while reviewing this PR, but which already exist with current main code:

  • Current implementation will leave behind 'dirty' tagging of IDs in case the operator is cancelled (addressed as part of the work done in !117304).
  • Undoing of purge operation works well, but when re-doing it (ctrl-Z), linked purged data is not deleted anymore, reported to keep track of it: #117303.

For reference, I created a similar PR (!117304) using/modifying the existing operator (OUTLINER_OT_orphans_purge), and the high-level WM_operator_props_dialog_popup API to show it. As a bonus, it also updates the numbers of to-be-deleted IDs when the user updates the settings.

image

Also, here is a simple test blendfile: linked_data_purge.blend. To get one directly unused local collection, and several indirectly unused IDs, both local and linked:

  • Unlink the local collection for the scene.
  • Clear the 'fake user' status of the unlinked collection in the Outliner.
Here is a summary of the high-level technical issues I have with the current code. I will ignore smaller issues for the time being. ***From initial review of the old PR:*** * Adding a new operator (`OUTLINER_OT_orphans_cleanup`), which is essentially an empty shell only used to trigger the creation of the pop-up. * Using low-level pop-up creation code (`UI_popup_block_invoke`), with a custom UIButton callback (`wm_block_orphans_purge`), that essentially duplicates the same code in existing operator's `exec` function (`outliner_orphans_purge_exec`). Re-using and improving the existing operator (`OUTLINER_OT_orphans_purge`) and using operator-popup API instead should be possible. ***New issues identified while working again on that PR:*** * The undo stack is broken in current PR (it seems to create a new undo step everytime the user updates an operator setting, and no undo step for the actual deletion operation). _This is a direct consequence of trying to by-pass the whole operator system and using 'raw' code like `wm_block_orphans_purge`._ * The reported amount of IDs to be deleted is not always correct. _The main reason is that there are inter-dependencies between the operator settings, e.g. `local` and `recursive` settings will affect the results for the `linked` data, etc._ * The reported amount of IDs to be deleted does not update when settings change. _This is also easily addressed when using the existing WM Operator/PopUp framework._ ***Issues identified while reviewing this PR, but which already exist with current `main` code:*** * Current implementation will leave behind 'dirty' tagging of IDs in case the operator is cancelled (addressed as part of the work done in !117304). * Undoing of purge operation works well, but when re-doing it (ctrl-Z), linked purged data is not deleted anymore, reported to keep track of it: #117303. ----- For reference, I created a similar PR (!117304) using/modifying the existing operator (`OUTLINER_OT_orphans_purge`), and the high-level `WM_operator_props_dialog_popup` API to show it. As a bonus, it also updates the numbers of to-be-deleted IDs when the user updates the settings. ![image](/attachments/fd4cba00-44a0-4264-b970-93f5d070ee69) Also, here is a simple test blendfile: [linked_data_purge.blend](/attachments/356e52ff-95f1-40ec-aa2a-2df86ebab214). To get one directly unused local collection, and several indirectly unused IDs, both local and linked: * Unlink the local collection for the scene. * Clear the 'fake user' status of the unlinked collection in the Outliner.

Another point I just realized: If you are renaming "orphan" to "unused", you should also tackle the other areas of the UI (starting with the name of the Outliner view itself).

We discussed this in the UI Module meeting and agreed this is not something to address here or yet.

Fair enough. I disagree with this decision (in fact, if the renaming from 'Orphaned' to 'Unused' is agreed on, I would rather have the name change done in existing Blender UI before landing this patch, as a cleanup step, through another PR). But if the UI module is happy with having two different names for the same thing in the UI, so be it.

> > Another point I just realized: If you are renaming "orphan" to "unused", you should also tackle the other areas of the UI (starting with the name of the Outliner view itself). > > We discussed this in the UI Module meeting and agreed this is not something to address here or yet. Fair enough. I disagree with this decision (in fact, if the renaming from 'Orphaned' to 'Unused' is agreed on, I would rather have the name change done in existing Blender UI before landing this patch, as a cleanup step, through another PR). But if the UI module is happy with having two different names for the same thing in the UI, so be it.

So, i think your original approach - just full initial caps - will be a good catch-all.

The convention in Blender is MLA, so we should just follow that.
https://developer.blender.org/docs/features/interface/human_interface_guidelines/writing_style/#ui-labels

> So, i think your original approach - just full initial caps - will be a good catch-all. The convention in Blender is MLA, so we should just follow that. https://developer.blender.org/docs/features/interface/human_interface_guidelines/writing_style/#ui-labels

On a practical level, I think the only missing thing from WM_operator_props_dialog_popup is the dual Cancel/Validation buttons, with customizable labels? Currently, this API will generate a single 'validation' button, and cancel is done by clicking outside of the popup or hitting escape.

I believe that adding an explicit cancel button for all these operator-based pop-ups would be beneficial (easier for users who are not familiar with Blender UI history) and consistent with other types of popups. This is a separate design & PR topic for the UI module though.

Perhaps the most straightforward way of getting this to work would be to change the new wm_block_confirm_create to call ot->ui between the message and the buttons, so that these new confirmation popups support showing operator properties.

> On a practical level, I think the only missing thing from WM_operator_props_dialog_popup is the dual Cancel/Validation buttons, with customizable labels? Currently, this API will generate a single 'validation' button, and cancel is done by clicking outside of the popup or hitting escape. > > I believe that adding an explicit cancel button for all these operator-based pop-ups would be beneficial (easier for users who are not familiar with Blender UI history) and consistent with other types of popups. This is a separate design & PR topic for the UI module though. Perhaps the most straightforward way of getting this to work would be to change the new `wm_block_confirm_create` to call `ot->ui` between the message and the buttons, so that these new confirmation popups support showing operator properties.
Author
Member

The current plan is that I will address a few different issues with this PR as described by Bastien:

  • Its invoke function should then popup the UI, and return CANCELLED (such that no undo step is stored for just showing the popup).
  • The popup data OrphansPurgeData should not store the operator itself. It could store the operator type (though this is not critical).
  • The 'Delete' button should then be an 'operator' button calling the 'exec' callback, and setting again the operator properties from the values stored in the OrphansPurgeData.
  • Not sure how to deal with the updates of the popup UI (needed when modifying options changes the amount of deleted IDs) in that case...

So get this into a shape where it could be accepted as is. However, I'd leave this as "WIP" while investigating integration with, and/or improvements to the generic WM operator popup code. Or, as mentioned by Brecht, integration of these into the new confirm code. It would be nice if all these things were a bit more consistent.

I had always planned on looking at improving the operator dialogs like the operator confirms, but thought the confirms were an easier "sell" to do first since they are so visible. My itch for improving this "Orphan cleanup" will be sated a bit when the new confirms are approved.

The current plan is that I will address a few different issues with this PR as described by Bastien: * Its invoke function should then popup the UI, and return CANCELLED (such that no undo step is stored for just showing the popup). * The popup data OrphansPurgeData should not store the operator itself. It could store the operator type (though this is not critical). * The 'Delete' button should then be an 'operator' button calling the 'exec' callback, and setting again the operator properties from the values stored in the OrphansPurgeData. * Not sure how to deal with the updates of the popup UI (needed when modifying options changes the amount of deleted IDs) in that case... So get this into a shape where it _could_ be accepted as is. However, I'd leave this as "WIP" while investigating integration with, and/or improvements to the generic WM operator popup code. Or, as mentioned by Brecht, integration of these into the new confirm code. It would be nice if all these things were a bit more consistent. I had always planned on looking at improving the operator dialogs like the operator confirms, but thought the confirms were an easier "sell" to do first since they are so visible. My itch for improving this "Orphan cleanup" will be sated a bit when the new confirms are approved.

@Harley think this one should be closed now, and a new PR created for the 'Managed Unused Data' new operator?

@Harley think this one should be closed now, and a new PR created for the 'Managed Unused Data' new operator?
Bastien Montagne requested changes 2024-02-12 10:41:05 +01:00
Bastien Montagne left a comment
Owner

needs to be updated or closed and re-created

needs to be updated or closed and re-created
Author
Member

Closing. This functionality was added by Bastien using a better method - a Props Dialog - here: #117304

Will propose a separate PR for the "Managed Unused Data" portion of this.

Closing. This functionality was added by Bastien using a better method - a Props Dialog - here: #117304 Will propose a separate PR for the "Managed Unused Data" portion of this.
Harley Acheson closed this pull request 2024-02-12 18:32:37 +01:00

Pull request closed

Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser Project (Legacy)
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#117242
No description provided.