Add-on preferences panel should open on activation #49133

New Issue

Sybren A. Stüvel · 2016-08-21T17:19:59+02:00

Sybren A. Stüvel commented

2016-08-21 17:19:59 +02:00

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.

**Blender Version** Broken: 2.78 testbuild 1 **Description of issue** According to the [new protocols for add-ons](https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.78/Add-ons#New_Protocols), 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.

Sybren A. Stüvel commented

2016-08-21 17:19:59 +02:00

Changed status to: 'Open'

Sybren A. Stüvel commented

2016-08-21 17:19:59 +02:00

Added subscriber: @dr.sybren

Brendon Murphy commented

2016-08-21 17:25:04 +02:00

Added subscriber: @BrendonMurphy

Brendon Murphy commented

2016-08-21 17:25:04 +02:00

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.

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 commented

2016-08-22 10:55:36 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2016-08-22 10:55:36 +02:00

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 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!).

Julian Eisel commented

2016-08-22 12:41:12 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2016-08-22 12:41:12 +02:00

I agree with @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.

Brendon Murphy commented

2016-08-22 13:23:00 +02:00

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.

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.

Peter Staples commented

2016-08-22 14:11:39 +02:00

Added subscriber: @PeterStaples

Peter Staples commented

2016-08-22 14:11:39 +02:00

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

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 ```

Julian Eisel commented

2016-08-22 14:18:45 +02:00

In #49133#387340, @BrendonMurphy wrote:
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).

> In #49133#387340, @BrendonMurphy wrote: > 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).

Antonio Vazquez commented

2016-08-22 16:15:57 +02:00

Added subscriber: @antoniov

Antonio Vazquez commented

2016-08-22 16:15:57 +02:00

I agree with @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 agree with @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.

Vuk Gardašević commented

2016-08-22 19:03:10 +02:00

Added subscriber: @VukGardasevic

Vuk Gardašević commented

2016-08-22 19:03:10 +02:00

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

What the tool does
What the shortcuts are
What the individual options are
What is the difference between addons maintained in trunk and external/third party ones
What Multiple addons with the same name found means and what is console (there is a recent bug post with it)
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)
That all the settings will be lost if the save user settings is not pressed
That an addon can crash Blender
That an addon is often developed to a certain use context and outside it crashes like there is no tomorrow
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)
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
That the wiki can contain old information, or that there is a wiki at all
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
It doesn't know how to navigate the addon preferences.
There are three different sections that filter addons: Search bar, Support Level, Addon Category and
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 don't think that the first time user argument is that convincing. Novice user doesn't know: - What the tool does - What the shortcuts are - What the individual options are - What is the difference between addons maintained in trunk and external/third party ones - What Multiple addons with the same name found means and what is console (there is a recent bug post with it) - 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) - That all the settings will be lost if the save user settings is not pressed - That an addon can crash Blender - That an addon is often developed to a certain use context and outside it crashes like there is no tomorrow - 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) - 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 - That the wiki can contain old information, or that there is a wiki at all - 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 - It doesn't know how to navigate the addon preferences. - There are three different sections that filter addons: Search bar, Support Level, Addon Category and - 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.

Brecht Van Lommel commented

2016-08-22 20:56:17 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2016-08-22 20:56:17 +02:00

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?

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?

Brendon Murphy commented

2016-08-23 02:20:12 +02:00

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.

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.

Peter Staples commented

2016-08-23 08:38:58 +02:00

In #49133#387387, @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?

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 #49133#387387, @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? 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.

Brendon Murphy commented

2016-08-23 12:37:37 +02:00

  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.

``` 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.

Bastien Montagne commented

2016-08-23 15:14:12 +02:00

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 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.

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 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.

Brendon Murphy commented

2016-08-24 00:47:50 +02:00

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

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

Sybren A. Stüvel commented

2016-08-26 11:03:53 +02:00

Thank you all for showing so much interest in this!

In #49133#387387, @brecht wrote:
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.

In #49133#387571, @mont29 wrote:
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:

opens the user preferences
scrolls to the appropriate add-on
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]".

Thank you all for showing so much interest in this! > In #49133#387387, @brecht wrote: > 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. > In #49133#387571, @mont29 wrote: > 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]".

Brendon Murphy commented

2016-08-27 07:55:52 +02:00

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.

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: ![has_prefs_icon.jpg](https://archive.blender.org/developer/F344386/has_prefs_icon.jpg) I'll have a talk with others to see if it's practical.

Bastien Montagne commented

2016-08-27 14:24:26 +02:00

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

Brendon Murphy commented

2016-08-27 19:56:57 +02:00

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

space_userprefs.diff

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

 "addons_prefs": "Panel Expands on Activation",

created roughly a couple of diffs to show the simple code to add preferences icon to addon via bl_info. [addons utils.diff](https://archive.blender.org/developer/F344974/addons_utils.diff) [space_userprefs.diff](https://archive.blender.org/developer/F344975/space_userprefs.diff) Using this code the addon author only needs to add this line to the bl_info ``` "addons_prefs": "Panel Expands on Activation", ```

Brendon Murphy commented

2017-02-07 10:30:51 +01:00

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.

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.

Aaron Carlisle commented

2017-02-07 16:04:08 +01:00

Added subscriber: @Blendify

Aaron Carlisle commented

2017-02-07 16:04:08 +01:00

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

Vuk Gardašević commented

2017-02-12 13:30:49 +01:00

Since the commit dd921238d9 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.

Since the commit dd921238d9 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.

Brendon Murphy commented

2020-01-17 07:35:16 +01:00

This is still valid and could be considered a paper cut?

There should be 2 things done here.

1st, There needs to be an Icon that is made visible if the Addon has preferences.
This solves 1 issue as the icon represents a visual indicator that the addon has extra information. I somewhat solved this in my outdated? diffs a few posts back. here: https://developer.blender.org/T49133#388135
The above could be improved. In the bl_info, an new list item "addons_prefs" which we could either have a default text in each addon: "Set Preferences on activation.

2nd as demonstrated by the above comment by @VukGardasevic the addon, when activated, should auto expand to display the addons preferences.

This solves this issue of the user not knowing if the addon has preferences to set and also expands the addon to expose the preferences which is good for the user.

Thanks.

This is still valid and could be considered a paper cut? There should be 2 things done here. 1st, There needs to be an Icon that is made visible if the Addon has preferences. This solves 1 issue as the icon represents a visual indicator that the addon has extra information. I somewhat solved this in my outdated? diffs a few posts back. here: https://developer.blender.org/T49133#388135 The above could be improved. In the bl_info, an new list item "addons_prefs" which we could either have a default text in each addon: "Set Preferences on activation. 2nd as demonstrated by the above comment by @VukGardasevic the addon, when activated, should auto expand to display the addons preferences. This solves this issue of the user not knowing if the addon has preferences to set and also expands the addon to expose the preferences which is good for the user. Thanks.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Add-on preferences panel should open on activation #49133