← All ideas
  • Published 9 Sep 2024

Workspace / Filter Addons - ON by default, please.

The ability to enable addons by workspace is a fine idea, but the current behavior makes it something I don't use due to the default state of the checkboxes.

By default - not using the feature, ALL addons are present for a workspace. When I want to trim this to clean up the sidebar, for example - I don't want to have to click 90 checkboxes to turn EVERYTHING back on, just to have 2-3 addons be disabled.

All the checkboxes should activate as ON (which is the default state, if the feature isn't used) when "FILTER ADD-ONS" is enabled, then the user simply uncheck a couple here and there.

Basically, the ON/OFF is backwards. I want to disable 3, not enable 87. manage.png

84.6%

Development Status: Open

Upvote 11 Downvote 2
thorn
9 Sep 2024

7 Comments

Lauloque

It would also greatly help to have button to check / uncheck all, be able to hold shift to check all the addons between last checked and newly checked item, and why not even an "invert" function that either inverts all the checkboxes states, or toggle their effect between filtering in/out.

3
thorn Author

I think all of the above are fine ideas, but at the most basic level, I just don't want to have to click 90 times and turn everything on, that was already on.

But yeah, even a button labeled Invert would do this.

Jordan-Henshaw

Haha! I have some code for this! It works! Doesn't look like I can put a screenshot here, but it's just an invert button below the UIList. This way it's just one button that addresses all complaints.

  1. User can rapidly disable or enable all on initial load
  2. User can perform more complicated invert operations
  3. Just one added button and only 18 lines of added code

I will figure out how to actually see if the Blender gods will like it and possibly get it added for real.

1
thorn Author

Jordan - I want to very much thank you for your interest, and trying to find a solution to this issue.

FWIW, I've just seen Pablo's recent note on Devchat - "We should just flip the default for the checkboxes." - and personally, that would make me completely happy. While I understand that at some future point, a user might want to do "another round" of disable/enable (that involves another 10 clicks) - to me it's near enough to zero to not matter. Even if I add another addon to blender and have to revisit the modified panel list one day, i'll only be turning off 4-5 addons. So starting from ALL CHECKED - that's fine.

Just throwing out some thought of "how much power does the artist need to keep checkboxes in a particular state" - for myself, pretty much none.

Thanks again. :)

Jordan-Henshaw

If I'm allowed to, which I think anyone is, I'm going to try to do this. Will stick with the "Enable/Disable All" button proposal since that would be pure Python. I think changing the default would be C++ since internal property registrations are C++, but that's not a property anyway, but I'm not immediately understanding how it's set up since I don't read C++. But adding a button is super easy.

But to change the default, it seems like the checkbox for turning the filtering on and off is a boolean registered in C++. OK. And the way the system works is it's basically just a list of all the add-ons that are enabled, and the add-on-specific check boxes are buttons that either remove or add the add-on to the list. OK. So the list currently starts off empty. To change the default, we need to run a for loop or list comprehension or something that adds all the addons to that list... on startup I guess? Not sure when exactly that code would run. So that's where I'm stuck on that front. I know how to do it from the context of an external add-on (event handlers), but not for internal Blender stuff.

Jordan-Henshaw

Another approach would be to allow click and drag to disable/enable all, but the reason that doesn't currently work is because these check boxes are operators, not properties. So you'd have to make quite a few changes to switch over to a property registered to each addon. And I'm definitely not knowledgeable enough to know why it's operator based and not property-based in the first place anyway.