Only fear I have is that, if the user installs an addon but hasn't yet enabled it, they won't be able to find it?

No need to fear, Blender still switches to 'All' and shows the just-installed add-on so that it can be enabled.

I wouldn't mind if add-ons were automatically enabled after installation, either, but that's for a different discussion/patch.

@Sybren A. Stüvel (sybren) Ok well in that case I suppose this is ok then.

Also can see the point that add-ons should probably be enabled by default - you would almost never not want that I think.

In D4886#111819, @Brecht Van Lommel (brecht) wrote:

I'm not sure sure about this. For a new user if only the enabled add-ons are shown, it's not obvious that there are more add-ons available. Instead they might think they have to press Install or go download them somewhere.

To me it's always been weird that "show enabled add-ons only" is in the same list as the add-on categories. From a technical point of view it makes sense (both are filters) but from a user's perspective not at all. A checkbox "show enabled add-ons only" next to the filter dropdown makes much more sense to me.

Also, changing the default should not be done by reordering the items, that breaks backwards compatibility for existing saved preferences.

This is not saved, otherwise I would have set it to Enabled, saved my preferences, and be happy. So what would it break, exactly?
Setting the default via default='Enabled' is also not possible as this EnumProperty has an items function, so reordering seemed like the only way to go about this.

@William Reynish (billreynish) @Brecht Van Lommel (brecht) what would you think of a UI like this?

This is just a mockup I made in Gimp, but it shows what I have in mind.

I think that's ok.

Adding my (unsolicited) two cents...

The prominence of the categories for "Official", "Community", and "Testing" seems odd. We already mark the individual addons with the Blender icon, so the big buttons at the top seem like an artificial division that end-users don't need to be concerned with with such importance.

The "Install" button is also not entirely clear either. Looking at this window it would be easy to guess that you select an item from the list, then click "Install" to make it work. It is not clear that "Install" is to Add an item to the list.

The "Refresh" button has the same prominence as the "Install" button beside it, but they are unrelated. It makes it seem so important that you wonder if it does more than just refresh the list. Seriously, it could be (mistakenly) thought of as "update" where it might check what is installed and download newer versions. That would be a logical conclusion based on its location and prominence. I think it should be just the icon without text.

The second level of categorization is a two-column list where most of the categories comprise only one or two things. Those categories need to be collapsed into a smaller and more logical list.

I think I'd end up with something more like this:

That's a clearer interface indeed. I don't understand the difference between "All" and "Installed", though.

@Sybren A. Stüvel (sybren) : I don't understand the difference between "All" and "Installed", though.

No, neither do I.

I think that crappy mockup was quickly whipped together by someone who didn't think it through because of insufficient level of caffeine.

In D4886#122474, @Harley Acheson (harley) wrote:

I think that crappy mockup was quickly whipped together by someone who didn't think it through because of insufficient level of caffeine.

Haha I think "Installed" is probably supposed to show Disabled addons only, enabled shows, well, enabled ones, and all shows all installed regardless of state.

Note that the existing design is intended to be consistent with the Themes and Keymap preferences. It doesn't have to be, but would be nice to keep these somewhat similar.

Install and Refresh are related, the purpose of the later is to refresh the list in case any add-ons were installed or removed outside of Blender.

I think the categories are important enough that they need the full text displayed, not just a filter icon. They are most closely related to the search field, and should be next to it.

@Duarte Farrajota Ramos (duarteframos) : I think "Installed" is probably supposed to show Disabled addons only, enabled shows, well, enabled ones, and all shows all installed regardless of state.

That would work. Or just remove the (dumb) "Installed" button and leave only "Enabled" and "All". You could certainly add "Disabled" if that is important enough, or just add it to the "filter" list if not.

@Brecht Van Lommel (brecht) : existing design is intended to be consistent with the Themes and Keymap preferences

Yes, those other sections suffer many of the same problems and should also be made less confusing. In fact the "Refresh" of Addons is replaced with a "Reset" on Themes which is way, way worse. But something for a different day. On Keymap we have a proper matched set of import and export. So we are only consistent on having some buttons in much the same place, but not in a way that helps. Each area should be the best it can be, regardless of the rest.

The more I think about it the more gets ripped out, so maybe I should stop. LOL. Here assuming that the categories list gets pruned down so each is broader:

@Harley Acheson (harley)'s proposals here seem quite nice IMO - more minimal, compact and also clearer.

We could do something like this, and then proceed to perhaps make similar changes to the Keymap section for consistency.

I don't like the blue "Enabled" replacing a checkbox. Those toggle buttons are quite clear when there are multiple, but when there is only one I vastly prefer a checkbox. The checkbox is a widely acknowledged UI element, whereas a blue rounded rectangle is not.

Apart from that I think it's fine to drop the Official/Testing/Community buttons, and to reduce the reload to an icon. Maybe the + for installing new add-ons is a bit too minimalistic?

For Install we should not use the + icon, and there should be text. Install is an important operation and there is no universal icon for it.

Adding the refresh button next to the search field makes it seems as if you have to press that to somehow refresh things when you are searching for already installed add-ons, which is not the case.

If we prefer not to have a checkbox for enable, it could just be an [All | Enabled ] enum.

I think this should remain two rows, trying to squeeze everything into one might look nicer but does not properly communicate things.

@Brecht Van Lommel (brecht) @William Reynish (billreynish) Is that an acceptance of this patch? Or do you have concrete input for me to improve it? For me my patch does what I want it to do (have a persistent setting "enabled add-ons only" checkbox), and IMO it's not disturbing other UI aspects.

Probably I would like to do it as an enum as Brecht says, but I can also change that after the fact.

Is there any rush to commit this?

Making a boolean into an enum isn't difficult, and may as well be done before applying the patch.

Also, is the intent to make this default? The patch doesn't do this yet.

There's no rush, I'm just fine with either solution.

I'm voting against using an enum, as having such an enum would give us three meanings of the word "All":

• all add-ons, as opposed to "enabled only",
• all categories, as opposed to only "Mesh" or "Animation",
• all support levels.

Note that each individual meaning of the word "all" can still not show all add-ons. For example, you could select the "Animation" category, then click the "All" button that's next to the "Enabled" button, and you would see all add-ons in that category, but not all addons. Let's not introduce another use of the word "all" that doesn't mean you actually get all.

To me it's very clear what a checkbox "Enabled add-ons only" would do in both the checked and unchecked states. A checkbox also has well-known, well-defined behaviour. However, having buttons (like the support levels) would show a conflict of behaviour. The support level buttons are toggle buttons (so behave like checkboxes) while the All/Enabled buttons only allow a single choice (so behave like radio buttons). Having two different behaviours with the same visual interface is not a good idea.

It could also be [ Installed | Enabled ].

In D4886#125204, @Brecht Van Lommel (brecht) wrote:

It could also be [ Installed | Enabled ].

True, but that would still show radio-like buttons and checkbox-like buttons in the same UI.

Title of patch is to change default, yet it was committed without changing default.

Was this on purpose?

If so, try keep patch titles up to date.

Good point, I've updated the title.