Plugin Request: Configuration before install

[PLUCKYHD]

Is there any way we could get some configuration options before the install of a plugin? Even if they have to be associated with the client.properties since the plugin wouldn't be started or running at this point. Just a request that would be nice to have as my plugin does allot during it's initial run but it would be nice for a user to adjust a couple settings before install of the plugin.

[GKusnick]

For example?

[stuckless]

Originally Posted by GKusnick

For example?

Well, an example that I had, was with a Null Encoder Plugin that I created last week. Part of the configuration for this plugin contains a location to a .mpg file that will used used as the recording stream when you schedule a recording from the epg. The encoder can't start up until the file is configured. Because the encoder can't start until the file is there, it would have been nice to prompt the user (in this case me) for the file on install.

This wasn't critical in my case, since this is a private plugin that I use for developing (I don't have a real tuner in my dev machine), but I can see cases where prompting for some configuration on install would be handy.

In phoenix, another case would be the central fanart dir. By default it has a location, but it's something that generally different for everyone... and required if you want to use fanart, so prompting for it on install would be handy and user friendly.

On the downside... I can see where this could become annoying if plugin authors start making all sorts of trivial settings forced on the user during installation.

[Fuzzy]

I can see perhaps an addition to the manifest to include some simple pre-config options. Perhaps boolean, string, path, and numeric would be enough? dunno... as long as there is a way to provide a decent description, and a default value.

[PLUCKYHD]

Fuzzy and Stuckless pretty much got what I wanted and a limit of a max of I don't know 5 or so wouldn't be so bad either. I mean they can configure after install but then I have to assume all are yes or true on install and don't like doing that so much.

[GKusnick]

I get that there are some options you want to configure once on first use. But I don't see that that warrants creating new machinery for pre-installation config. Just default those settings to "not configured" and code your plugin to do nothing until they've been set to something sensible.

If the plugin has a UI component, then it shouldn't be hard to find a place in the UI to prompt the user for initial config post-install. If the plugin has no UI component (other than its config screen), put language in the description and/or setup instructions to remind users to configure it after installation.

Bottom line is that there doesn't seem to be a real problem here that can't be solved within the existing config mechanism, or that justifies complicating the end-user experience by splitting plugin config into two disjoint groups of settings for pre- and post-installation config. Remember the whole point of the new plugin system is to make plugin installation simpler for users, not for plugin devs. If we have to work a little harder to make their lives easier, that's the right tradeoff to make.

[Fuzzy]

I'm thinking more along the lines of the end user here. Say i go to the plugin manager, see two plugins I want to install, one depends on, say, phoenix api (for fanart). The first thing that's going to happen is the phoenix api will be installed. With the 'on first occurrence' style config that you are talking about, it'd be hard to control what order those pop-up option panels get presented. It could even be a couple minutes later, and after installing a bunch of plugins, it might not be as intuitive to the user what they are trying to configure. If, instead, as the plugins were installed, each would pop up it's options, with the defaults selected, and continue being the default button, It would be much clearer WHAT you are configuring.

It would also help to indicate where someone would go to get BACK to those options. Say someone installs a fanart STVi, which installed phoenix... they never implicitly installed phoenix, so they may not even know it exists. So say they want to configure their FanArt folder.. where do they go to do that? they'd probably first try to go to the fanart STVi's plugin config. however, if they were presented with 'Phoenix API' options upon install, it might clue them in to the real location of those settings.

[GKusnick]

I didn't mean to suggest there should be config dialogs popping up at random as you navigate the UI. Rather, UI mod plugins that require initial config before they can do anything sensible should reflect that in their display. So if the FanArt folder hasn't been set yet, users should see a "FanArt not configured" graphic where they would otherwise see fanart. In some cases it might make sense for this kind of passive prompt to be clickable, whereupon it takes you into the plugin manager's config screen for that plugin.

A string of popup dialogs during plugin installation is, I suppose, better than popping them up at random. But better still would be to keep all the config in one place, accessible through the plugin manager, so users always know where to go to configure their plugins.

I'm also somewhat skeptical of the idea of settings that can be configured just once and then never changed again. If I change my mind about where I want my fanart stored, I should be able to do that. And the place I go to do it should be the same place I set it originally, namely the plugin manager's config screen for that plugin, not some one-time-only popup that happened during plugin install.

[PLUCKYHD]

Well I guess we will have different views. My thought was for the user experience which is hampered in my plugin due to not being able to config things on install. Certain things have/must be configured for my plugin to run correctly and now currently there is no way to "force" the user to config this options and I know if I rely on the plugin settings (which are hidden to much in the settings IMHO) then I know I will get post after post of "why isn't this working" and "how do I configure this correctly to work". As of current I am guessing and setting the values to defaults the problem is that is can create allot of excess files that may or may not be needed for every uses (it scales images based on these settings). I was thinking of end user experience and also think it would be great to be able to update the UI while a plugin is installing with current status updates other then the default "please wait installing/starting plugin" that popups up. As in the case of my plugin on first start it takes a while to perform all the actions that needs to be done, but that is another story.

Like I said it was just something I would like to see so I suggested it. To me it would have allot of benefit in my plugins as stated above the default config settings are difficult for allot of users to find. Plus they can't access those or any ui settings I add somewhere in the UI until after the plugin is installed so again defeating me purpose. It just seems silly to me to ask a user to install a plugin and oh yeah then you have to navigate to the settings and set your settings or it won't work granted I could leave the default but this is less than ideal IMHO.

[GKusnick]

For the record, I have no problem with you making this kind of suggestion. But I still think there are ways to get what you want without creating a whole parallel config mechanism that would be active only during plugin install. Here's how I'd do it:

Add a method to the PluginAPI called PluginNeedsConfig() or something along those lines. During startup, if a plugin detects that it hasn't been configured yet (i.e. its "must configure" properties are all in the default "not configured" state), it can call this method to tell the core that it wants to be configured.

There'd be another method, GetPluginsThatNeedConfig(), that the UI could call to retrieve a list of plugins that need to be configured. This would be handled similarly to the "Restart Now?" prompt you get after installing or upgrading plugins. So once any required restart had been done, the user would be prompted to configure any newly installed plugins that require it, with buttons that go straight to the config screens for those plugins using the existing config mechanism. So the problem of users not being able to find the config screen becomes a non-issue.

If there's any long-winded initialization your plugin needs to do on initial config, this gives you a chance to do it post-install, at a time when the user is expecting it.

Moreover, you wouldn't be limited to calling PluginNeedsConfig() on the first installation of your plugin. You could call it any time your start() method detects a situation in which it needs user input to configure some settings (e.g. on upgrade to a new version of your plugin). The logic by which you make such decisions would be entirely up to you, using whatever Java code will do the job. That kind of flexibility would be a lot harder to achieve in a one-size-fits-all, XML-driven pre-installation dialog. (Personally, I'm getting pretty tired of the SageTV installer asking me each time I upgrade if I want to configure support for tuner cards and remotes I don't own. In my view those random pre-installation options should be banished to the post-install Config Wizard where they belong.)

[PLUCKYHD]

That would work in allot of ways. The only issue is if pluginneeded configuration sage would have to wait to call start() as it is now start is called immediately.

Ps I know you had no problem sorry if I sounded differently. I know my coding knowledge is minor compared to yours and others that is why I like the open suggestions like the one you made above.

[PLUCKYHD]

Deleted after re reading gregs suggestion again he covered this

[Fuzzy]

Perhaps it could be nothing more complicated than being able to tag the plugin as 'must config'. Then, it will automatically show the PluginConfig options after install.

[GKusnick]

Originally Posted by PLUCKYHD

The only issue is if pluginneeded configuration sage would have to wait to call start() as it is now start is called immediately.

My thinking is that it would call start() normally. It would be up to the plugin to detect in its start() method that it's not fully configured yet and internally disable or noop out those portions of its function that can't work without further configuration. setConfigValue() could then re-evaluate and decide whether it's now safe to enable those functions or not. The plugin itself has the knowledge to make these decisions about its own internal workings; the plugin manager does not.

Originally Posted by Fuzzy

Perhaps it could be nothing more complicated than being able to tag the plugin as 'must config'. Then, it will automatically show the PluginConfig options after install.

I thought about that, but there's still the question of when that tag should be enforced (on first install? upgrade? disable/enable? etc). So I decided it's simpler just to call the plugin's start() method and let it decide whether/when to flag itself as needing further config.

[Fuzzy]

What about simple STVI's that don't HAVE a start() method?

[GKusnick]

Originally Posted by Fuzzy

What about simple STVI's that don't HAVE a start() method?

They have an ApplicationStarted hook. (Although in that case they'd need to pass in the plugin ID or something so the core knows which plugin is requesting configuration.)

If your next point is "but STVIs don't use the standard config machinery", my answer is that they could and should; see this discussion. (I have a 95% working implementation of this, but the remaining 5% is waiting on some core bug fixes in 7.0.12.)

[PLUCKYHD]

Originally Posted by GKusnick

They have an ApplicationStarted hook. (Although in that case they'd need to pass in the plugin ID or something so the core knows which plugin is requesting configuration.)

If your next point is "but STVIs don't use the standard config machinery", my answer is that they could and should; see this discussion. (I have a 95% working implementation of this, but the remaining 5% is waiting on some core bug fixes in 7.0.12.)

I thought about the application started hook by then I thought this should e configured before restart but maybe not.. I would be easy enough to delay the start() initially I think and put something jn the application started hook I am going to think on that a bit.

As for the other can't wait to see what you got going. I agree to a point.My plugin of course has both and I am moving away from the plugin configuration methods after this discussion I think. To me it is too confusing to the user to say install the ui plugin but configure from the general plugin you didn't even know existed as a dependency. I agree it is easier put in a stvi and less confusing to the user.