UI: Cleanup Dialog to Manage Orphaned Data #117242
No reviewers
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
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
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
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
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
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
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#117242
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "Harley/blender:ManageData2"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
This patch replaces all six menu items with one item. And also adds a new item:
"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:
"Manage Unused Data..." brings up a window with Outliner in "Orphan Data" mode so that you can have more fine-grained control:
Unresolved Review Questions:
This is a recreation of a PR that is now closed, but can be found here.
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.
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)
We discussed this in the UI Module meeting and agreed this is not something to address here or yet.
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
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.
@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.
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
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)
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 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.
Here is some feedback on a fairly high, general level.
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:
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:
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:
OUTLINER_OT_orphans_cleanup
), which is essentially an empty shell only used to trigger the creation of the pop-up.UI_popup_block_invoke
), with a custom UIButton callback (wm_block_orphans_purge
), that essentially duplicates the same code in existing operator'sexec
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:
This is a direct consequence of trying to by-pass the whole operator system and using 'raw' code like
wm_block_orphans_purge
.The main reason is that there are inter-dependencies between the operator settings, e.g.
local
andrecursive
settings will affect the results for thelinked
data, etc.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:For reference, I created a similar PR (!117304) using/modifying the existing operator (
OUTLINER_OT_orphans_purge
), and the high-levelWM_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.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:
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.
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
Perhaps the most straightforward way of getting this to work would be to change the new
wm_block_confirm_create
to callot->ui
between the message and the buttons, so that these new confirmation popups support showing operator properties.The current plan is that I will address a few different issues with this PR as described by Bastien:
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?
needs to be updated or closed and re-created
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.
Pull request closed