Page MenuHome

Rigify: Addon Prefs & Feature Sets UI
ClosedPublic

Authored by Demeter Dzadik (Mets) on Aug 10 2020, 5:25 PM.

Details

Summary

This patch removes the two drop-down menus from the Rigify addon preferences, replacing it with a checkbox and a UIList.

Before:

After:

There is also a small bit of new functionality. The following keys are now recognized in the rigify_info dictionary, similar to Blender addons:
'link', 'doc_url', 'tracker_url', 'description', 'author', 'version', 'warning'.
They will be displayed underneath the UIList when the feature set is the active one in the list.

Ideas for future
I think this UI better enables us to do some cool things in the future:

  • Disable feature sets without uninstalling them.
  • Have a base set of feature sets in the list that aren't actually installed. Instead, selecting them would just reveal a button that opens their repository URL. This could be used for officially supported but external feature sets, such as what Legacy should be.

Feedback welcome.

Diff Detail

Event Timeline

Demeter Dzadik (Mets) requested review of this revision.Aug 10 2020, 5:25 PM
Demeter Dzadik (Mets) created this revision.
Demeter Dzadik (Mets) edited the summary of this revision. (Show Details)Aug 10 2020, 5:28 PM

List was using module name instead of UI name

The preferences idea sounds interesting, but this doesn't specify a place to store those preferences, so it can lead to a mess with every feature set doing random stuff.

rigify/__init__.py
256

This somehow doesn't look like a header in the ui - maybe at least add ":" to the end?..

rigify/feature_set_list.py
226

Is the new set really guaranteed to be the last in the list? I have a feeling the order may be undefined.

258

The if stuff kind of looks messy, especially the == -1 comparison - don't use equals when you really want to detect negative numbers.

Even if the suggested solution seems more UI consistent for an experienced blenderhead, i honestly find that the “install from file” and “remove” buttons makes more sense and are self explainatory for the user. Still there’s plenty of room for improvements. Would be nice to have some UI giudines for preferences from UI team.

Even if the suggested solution seems more UI consistent for an experienced blenderheads, i honestly find that the “install from file” and “remove” buttons makes more sense and are self explainatory for the user. Still there’s plenty of room for improvements. Would be nice to have some UI giudines for preferences from UI team.

An alternative for this would be to organize things the same as the addon list itself, with expandable sections for the detailed info about each feature set.

Demeter Dzadik (Mets) updated this revision to Diff 27882.EditedAug 18 2020, 6:44 PM

Thank you both very much for the feedback!

The preferences idea sounds interesting, but this doesn't specify a place to store those preferences, so it can lead to a mess with every feature set doing random stuff.

This is a good point, I will think about this, don't have a proposed solution at the moment.

the “install from file” and “remove” buttons makes more sense and are self explainatory for the user

I agree. I brought back the "Install Feature Set from File..." and "Remove" buttons. Adding and removing things from the list is a big operation and the clarity about what those buttons do is more important than compactness.

An alternative for this would be to organize things the same as the addon list itself, with expandable sections for the detailed info about each feature set.

I considered the idea of mimicking the addons UI with drop-downs to show the details, but I'm actually not a fan of the addons UI to begin with because it results in very long vertical UI and lots of scrolling. That said, I can see value in consistency, so could still go for it, but I definitely have a preference towards a UIList instead.

Demeter Dzadik (Mets) marked 3 inline comments as done.Aug 18 2020, 6:47 PM
Demeter Dzadik (Mets) added inline comments.
rigify/feature_set_list.py
226

You're right, the order is undefined. Making the order defined seems tricky, but I do want to make sure the newly added feature set is the active one, so I just do a search now to find the correct index.

Demeter Dzadik (Mets) updated this revision to Diff 27902.EditedAug 19 2020, 12:38 PM
Demeter Dzadik (Mets) marked an inline comment as done.

The preferences idea sounds interesting, but this doesn't specify a place to store those preferences, so it can lead to a mess with every feature set doing random stuff.

This is a good point, I will think about this, don't have a proposed solution at the moment.

It would be interesting to find a way to either:

  • Allow feature sets to add additional bpy.props to the RigifyPreferences class in some way
  • Register their own bpy.types.AddonPreferences class

But I tried both of those and failed, so I decided not to bloat this patch with this idea.

All feedback should now be addressed, let me know if there's any further feedback!

Demeter Dzadik (Mets) edited the summary of this revision. (Show Details)Aug 19 2020, 12:46 PM

i think there should be at this point some way of just disabling the external featureset rather than just removing it. Also a "restore defaults" options would be beneficial. We could include in defaults @Nathan Vegdahl (cessen) features and leave it disabled by default.

another UI option could be using the same preference style as pie menus add-on:

i think there should be at this point some way of just disabling the external featureset rather than just removing it. Also a "restore defaults" options would be beneficial. We could include in defaults @Nathan Vegdahl (cessen) features and leave it disabled by default.

Absolutely, it was always my intention to propose this in a future patch.

another UI option could be using the same preference style as pie menus add-on

Even if the per-feature-set preferences become a thing in the future, there just isn't a user story that involves seeing the settings or information about multiple feature sets at the same time. That's in addition to what I mentioned previously:

I'm actually not a fan of the addons UI to begin with because it results in very long vertical UI and lots of scrolling.

And that ofc applies to the current addons and hotkeys UI in Blender. I think they haven't seen any major change since 2.5, so I don't much value being consistent with it. But that's me ofc. If I haven't convinced you then I can change the patch to be more consistent with existing UI with drop-downs to reveal info about each featureset.

In D8519#210014, @Demeter Dzadik (Mets) wrote:
If I haven't convinced you then I can change the patch to be more consistent with existing UI with drop-downs to reveal info about each featureset.

i don't think you have to convince me. I am just here to discuss possible solution and potential issues with new design.

My point is the pie-menu proposal had some consistency reasons and from an user pov a compact, expandable and clear overview of the featuresets. If we look at the future of this implementation maybe a similar concept (even if has some difference in general layout) could be beneficial for users.

That said, i believe we can discuss about my first revision to your proposal as a starting point if you prefer it.

Fair enough. The only benefit I saw to the dropdown lists is being able to see details about multiple things at once, which to me is more a burden than a benefit, but if anyone can see real benefits to it then it can be changed pretty easily on the code side whenever. The checkboxes and graying out of entries that you proposed is definitely possible, it's precisely what I was planning for future in fact! ^^

This revision is now accepted and ready to land.Nov 7 2020, 3:14 PM
This revision was automatically updated to reflect the committed changes.