Add-on preferences panel should open on activation
Open, NormalPublic

Description

Blender Version
Broken: 2.78 testbuild 1

Description of issue
According to the new protocols for add-ons, certain add-ons need more actions from the user than simple activation, before they do anything. This is an excerpt from the pie menu example:

  • With Pie menus, First you activate the addon & nothing happens!
  • You need to expand the Addons Preferences.
  • From here you can individually activate the menus you like to use.

This is bad UI design, as it requires the user to know that activating the add-on does nothing. Blender also requires them to click a button that doesn't appear any different than before (and thus doesn't visually indicate there is something else to see there now).

Possible solution
Automatically opening the add-on's preferences panel when it is activated would help a lot. At least this allows the user to see that there are options to inspect, and possibly activate.

Details

Type
Design
Sybren A. Stüvel (sybren) changed Type from Bug to Design.

I fully agree, many addons both in blender & externally developed, use addons preferences for settings.
Currently there's no way for users to know (without reading docs) that the preferences exist.
The simple rule here should be that:
all addons when activated should expand their bl_info panel, which in turn exposes the addons preferences also.
this is much needed.

Bastien Montagne (mont29) triaged this task as Normal priority.Aug 22 2016, 10:55 AM

I disagree here. Would find it very annoying to have a whole bunch of settings spreading across my screen just by enabling an addon, this is not always wanted, by far.

Further more, knowing addons can be expanded (with the arrow) to show more info and settings is basic Blender UI knowledge - also consistent with a bunch of panels all over UI that are by default closed, etc.

What bothers me here is that pie addons come with 'everything disabled' default settings. That is stupid imho, if you enable it, you want to get by default reasonable useful settings, not to have to additionally go enabling everything yourself.

Remember: we aim at providing good default settings, with possibilities to tweak them for powerusers. Not to overwhelm everyone with tons of buttons (we already have too much!).

I agree with @Bastien Montagne (mont29) on this. Reasonable default settings work much better than spawning the settings. It's like saying to the user "you enabled this setting but we force you to look at all the other settings now". Really don't like that.

Whilst I understand peoples concerns & have already attempted changing the defaults to activate all at once, this is a new system, recently introduced. It's easy. ergonomic & solves more problems than it creates. Users will & are quickly adapting.
feedback is being noted & worked on.
thanks.

Can force an addon to expand by putting this code in register.

def register():
    import addon_utils

    mod = addon_utils.addons_fake_modules.get(__name__)
    if mod is not None:
        info = addon_utils.module_bl_info(mod)
        info["show_expanded"] = True

Whilst I understand peoples concerns & have already attempted changing the defaults to activate all at once, this is a new system, recently introduced. It's easy. ergonomic & solves more problems than it creates. Users will & are quickly adapting.
feedback is being noted & worked on.

Not sure what you refer to when you say people will adapt to it (to the default enabling or to the auto-expanding). If it's about auto-expanding, I don't think it's as easy as saying users will adapt. I won't accept such a change for the reasons given above (in comments from Bastien and myself).

I agree with @Bastien Montagne (mont29), the default panel must be closed. The point here is to define a valid default values for the add-on.

The preferences must be an option to customize, but never a requirement for enabling the add-on. If the default values are not the "best" options by default, the first time user doesn't know what values use. It's reasonable to think that the add-on's developer knows better what are the best values for these parameters.

I don't think that the first time user argument is that convincing.
Novice user doesn't know:

  1. What the tool does
  2. What the shortcuts are
  3. What the individual options are
  4. What is the difference between addons maintained in trunk and external/third party ones
  5. What Multiple addons with the same name found means and what is console (there is a recent bug post with it)
  6. That activating an addon overwrites Blender default shortcuts or other addons (depending on how it is written it can lead to the shortcut not working at all until restart if the addon is disabled)
  7. That all the settings will be lost if the save user settings is not pressed
  8. That an addon can crash Blender
  9. That an addon is often developed to a certain use context and outside it crashes like there is no tomorrow
  10. That many addons use scene properties stored in the blend file (depending how it's written, even if the addon is disabled, it leaves pointless litter around forever)
  11. They don't know how to or where to install an addon, or save it from the developers github page at all - if it shows as text on the web page
  12. That the wiki can contain old information, or that there is a wiki at all
  13. That is using an old version of the addon that doesn't work anymore with newer versions of Blender or the addon is deprecated by being included elsewhere
  14. It doesn't know how to navigate the addon preferences.
  15. There are three different sections that filter addons: Search bar, Support Level, Addon Category and
  16. depending on their filtering state no addons can show up.

Sorry for the rant. :)

The problem here we have is that we're reaching the point where the current addon system is starting to feel the limitations of scalability.
It's not only what sensible defaults are, but it's also about:

Activation system

Conflicts between different addons and Blender's tools

Information/Feedback/Discoverability

Customization/Preferences

UI Layout (any complexity adds to scrolling)

User Preferences in General with it's design semi-broken state (Themes, Input, :|)

Supporting growth in addon number and complexity

Anyway, if there is no problem with the activation of pies (stretching the current system to allow individual activation) some of them can be left on as default.

I guess the original reason for opening this task is the Blender Cloud addon, where you need a username and password for it to work at all? In that case prompting for the information in some way would be good I think.

Maybe there's a better way to do it, a popup when enabling, a popup the first time cloud functionality is actually used, a one line UI even if the addon is collapsed, .... I don't have a strong opinion on that.

About the implementation that was committed, I don't think it distinguishes between registration on addon activation and registration on startup? So it would always expand on startup?

As my commit https://developer.blender.org/rBA2a290714da05a20f285c45c1f8e04425b919654d was audited, I've reverted the "Official Pie Menu addon".
Unless a solution is found quickly for "Official Pie menus" having activation on by default, I'm left with little choice but to fully revert "Official Pie Menus" back to their original state.

Compromise is the solution I was looking for here.
In their original state, "Official Pie menus" activated & "took over" several key key maps, with no recourse for the user to over write these keymaps other than manually editing. They did not respect usual behavior of key map hierarchy: usually the last activated addon will over rule the prior addon key map. In Official Pies this did not happen, causing conflicts if the user wanted to use specific keys with another addon.
Not good behavior.

As for my 3d viewport pies addon, I;m happy with the new introduced behavior. Both the individual activation (to prevent conflicts & to give user choice of what to activate) and the auto open preferences on activate are very intuitive & user friendly.
I would not look at this method atm for any other addons as 3d view pies is a unique case.

Thanks.

About the implementation that was committed, I don't think it distinguishes between registration on addon activation and registration on startup? So it would always expand on startup?

As is, It doesn't expand on startup if enabled by default, it does however expand on F8 (reload). Adding another test using addon_utils.check(...) or in the case of pies checking against existing keymaps, or having a first_run bool in preferences could be possible workarounds.

I actually like the idea of the one line UI, or similar... as the only thing currently available if there is some warning for the user in registering is to print something to the system console.

In T49133#387387, @Brecht Van Lommel (brecht) wrote:

About the implementation that was committed, I don't think it distinguishes between registration on addon activation and registration on startup? So it would always expand on startup?

No it does not auto expand on start up even when enabled and saved as user settings, the addon displays as usual (closed at start up) and all preferences are saved as normal.

Use Cases
Addons that have addons preferences which contain valuable & hidden settings can "unhide" the preferences so the user has an opportunity to know the addon has settings.
Addons that use sub-activation to activate addons within the addons preferences structure. (Pie menu's example)

Addons Preferences Sub Addon Activation & Auto Drop Down.
The workflow is very simple:
Enable the addon,
The addon automatically opens the addons bl_info & addons preferences
From there the user can choose which addons/settings to activate.
In the test case of pie menus the user first enables the addon which in turn auto opens the bl_info panel & displays the sub menu options. in this case, to activate a choice of multiple pie menus.

Why?
To be honest, this all started when I looked at "Official Pie Menus Addon"
First thing I noticed was a lack of any indication of what the hotkeys were, what menus were being activated, I was offline at the time & literally had to read the code to find out the hotkeys.
Second thing I noticed was Pie menus overwrote/overrides any of my custom hot keys or activated addons keys & also prevented addons activated after pie menus to register their hotkeys. with official pies it was all or nothing, you activate the addon & your stuck with the hotkeys & pie menus.

Solution?
It would have been easy to split up the pie menus addon into multiple (individual addon) files & use the current category system.
This would bloat the amount of addons in Blender significantly, so I needed to keep them together for that reason & development.
(who want's to look through many files that relate to each other so close, spread out everywhere?)

I had however been using sub addon activation to test & control large amounts of addons for over 12 months.
Pie menus seemed & are very well suited for this, so I set about to convert the sub module addon system.

User Benefits
From a user perspective it's very easy, especially with the auto expand.
Enable the addon, the sub activation menu drops. Then Choose which elements to activate.
Hot Keys are displayed for each activation giving the user opportunity to know what they are enabling & which hotkeys are affected.

Summary
Whilst this is a new system for Blender & new territory for addons, I like to look at the positives here. Better usability, less conflicting key maps, choice of which hotkeys to activate, hotkey listings, less conflicts, less individual addons in Blender addons folder.

As a proof of concept, I would like to continue using the full sub menu activation & auto drop down in my 3d view pie menus.
"Official Pies" could also greatly benefit from this as it ensures compatability with other addons & key map preferences.

Thanks.
Brendon.

I don’t understand why you want to revert all your work… It’s deadly simple to enable most used/useful pies by default, period.

'Splitting' Pie addons in 'submodules' that can be enabled independently is a very good thing, no doubt about it.

But automatically filling the screen with options when enabling an addon is bad, on bith UI and UX sides, I hate having that stuff personally when I enable pie addons now.

Think @Brecht Van Lommel (brecht) points are valid here, we rather want a (nice and non-intrusive) way to inform user this addon has settings, and when defining those settings is required (like the BlenderID one) - which *should not* be the case of pie addons. Would propose a simple icon here, we already have one for 'experimental' addons, easy to add one for addons with custom settings (the gearing one, with e.g. a variant with read eaxclamation point when editing settings is mandatory to get addon working).

Besides, what ever solution we choose, it should be implemented in the addon handling code, not hacked by addons themselves.

In fact, I think we could solve the 'mandatory settings' issue in a more generic way, usable across whole Blender UI: add a new 'PROP_NO_DEFAULT' RNA property flag (or re-use PROP_REQUIRED one, which is only used by RNA functions currently, and has pretty much the same meaning?) . Would mean 'this property cannot have a meaningful default value, so user has to define it explicitly'.

We could then use this flag to make matching UI widget 'invalid' as long as some value is not explicitly set, and addon handling code could detect those too to use 'settings requested' icon in compact display.

Note that currently, 'is_set' only works with IDProperties (mostly used for operator ones), so would not work for everything, but would be enough to handle addons case.

hi mont29, thanks for the valid input, of course I don't want to revert my work, I'm just looking for different solutions & weighing up options.
I agree there should be a more generic way to do this, I'll continue working on this today to see if I can find answers to some initial issues.
Thanks

Thank you all for showing so much interest in this!

I guess the original reason for opening this task is the Blender Cloud addon, where you need a username and password for it to work at all?

In a way, yes, but slightly more convoluted. The Blender ID addon queries for username/password, while the Blender Cloud addon just uses the authentication token obtained by the Blender ID addon.

However, the immediate reason to open this ticket was the fact that the Pie Menu add-on didn't do anything after activation, even though older versions only needed activation to work.

Maybe there's a better way to do it, a popup when enabling, a popup the first time cloud functionality is actually used, a one line UI even if the addon is collapsed, .... I don't have a strong opinion on that.

Maybe a login popup might be a good idea, yes. What I do not like (and I'm not implying that you suggested this, just want to get this out here) is a message that tells you to open the addon preferences. If a program needs to tell me what to do in the GUI itself, it should just do it instead of asking me.

Besides, what ever solution we choose, it should be implemented in the addon handling code, not hacked by addons themselves.

I fully agree here.

In fact, I think we could solve the 'mandatory settings' issue in a more generic way, usable across whole Blender UI: add a new 'PROP_NO_DEFAULT' RNA property flag (or re-use PROP_REQUIRED one, which is only used by RNA functions currently, and has pretty much the same meaning?) . Would mean 'this property cannot have a meaningful default value, so user has to define it explicitly'.

We could then use this flag to make matching UI widget 'invalid' as long as some value is not explicitly set, and addon handling code could detect those too to use 'settings requested' icon in compact display.

That sounds very good to me.

It would be even better if we also had a way to present the user with a button which:

  1. opens the user preferences
  2. scrolls to the appropriate add-on
  3. opens its preferences panel

With such a button, an add-on/Blender could show something like "this add-on requires you to set preferences [button]take me there[/button]".

hi, looking into the ui code I've coded in to add an icon to the addon info as a visual indication that an addon has preferences:


I'll have a talk with others to see if it's practical.

Yes, that’s exactly the kind of UI feedback I had in mind. ;)

created roughly a couple of diffs to show the simple code to add preferences icon to addon via bl_info.

Using this code the addon author only needs to add this line to the bl_info

"addons_prefs": "Panel Expands on Activation",

hi, I would like to revisit this,
I could make all needed changes & help Blendify with any needed wiki/manual updates.
Currently there's no nice visual indicator that an addon has "Addons Preferences"
Addons preferences often supply users with configurations for their specific workflows.
This is something easy to apply to release addons that could use & not a major change.

The manual is OK it is just the add-ons that might need help

Since the commit rBdd921238d922 there is already an operator that can access individual add-ons and expand it's preferences - WM_OT_addon_userpref_show in wm.py.

It can be accessed by bpy.ops.wm.addon_expand(module="some addon module name")

I think that can be modified to fit this purpose.