STVi with small jar needs to be configured

[ehanekla]

Hi,

I am currently reading the docs and the forum but I may have missed something: I plan to create a STVi with minor changes to the UI. The STVi uses a Java class in a jar file that I created. The Java logic needs a configuration, simply a file path, and a string. Of course it would be sweet to configure my plugin with the SageTV Plugin Manager! But as far as I can see I would need to create two different plugins: one "STVi" plugin for the UI and another "Standard" plugin with this special interface implementation, which allows configuration.
Is this the only solution? I would not want to tear a simple plugin into two.

Thanks,
Eyk

[GKusnick]

This is a known constraint with the plugin system. The rules for enabling/disabling STVIs are different than the rules for Standard plugins (because STVIs have STV dependencies that Standard plugins don't have). So you can't have a plugin with both an STVImport and an ImplementationClass.

So your choices at present are to package your STVI as a separate plugin from your (Java) config code, or else roll your own config UI in Studio instead of using the standard plugin config UI.

Ideally, instead of everyone rolling their own, it should be possible to factor out some common config UI elements into a generic framework that can be shared by many STVIs. This framework itself could then be packaged as an STVI that other STVIs depend on. If and when I get around to writing an STVI that requires significant config UI, I'll probably try to structure it this way (unless somebody else gets there first).

[ehanekla]

Thanks for your answer!

I was afraid to hear that. The plugin system is a really, really nice idea, but with such a limitation it's just 90%. In my opinion Sage should address that. It's still beta phase, isn't it?

Eyk

[PLUCKYHD]

Originally Posted by ehanekla

Thanks for your answer!

I was afraid to hear that. The plugin system is a really, really nice idea, but with such a limitation it's just 90%. In my opinion Sage should address that. It's still beta phase, isn't it?

Eyk

I don't really see it as a limiation having to do two seperate plugins, the trade offs are well worth it. You just simply male your stvi dependent on the implentation plugin. Now if we could add a *hidden attribute that would still be great as well. Then make hidden by default but if users wanted to see them they could. Also I stay away from the plugin settings myself as I can't get the current context being used since the plugin is running in the service so it elimates allot of configuration options in my addins

my 1 cent

[ehanekla]

Also thanks for your answer!

Originally Posted by PLUCKYHD

I don't really see it as a limiation having to do two seperate plugins, the trade offs are well worth it. You just simply male your stvi dependent on the implentation plugin.

Of course I don't have a problem to develop like that. UI and BL should be decoupled anyway. I just see it from the end user's point of view. I would not want to see too much entries in the plugin list.

Originally Posted by PLUCKYHD

Now if we could add a *hidden attribute that would still be great as well. Then make hidden by default but if users wanted to see them they could.

Hmm, I can't really imagine how this might work. So the "configurable jar" is in a plugin which is set to invisible. Then it also won't appear in the list of installed plugins and cannot be configured until it is set to visible, right? That sounds like 90% again. Or did I get you wrong?

I like GKusnicks suggestion very much. I think that this would be a base functionality that should be implemented in the base product.

This is only my 2 cent, of course

Eyk

[skiingwiz]

Originally Posted by GKusnick

Ideally, instead of everyone rolling their own, it should be possible to factor out some common config UI elements into a generic framework that can be shared by many STVIs. This framework itself could then be packaged as an STVI that other STVIs depend on. If and when I get around to writing an STVI that requires significant config UI, I'll probably try to structure it this way (unless somebody else gets there first).

It would be nice (in my opinion) if STVi plugins could be configured from within the the plugin manager like General plugins can. Maybe an extra XML file with the import that defines the properties to be configured, data types, and legal values. (Much like an XSD.) The plugin manager could then generate the config display like it does for General plugins. I would think that this method would be good enough for the majority of STVi plugins.

[GKusnick]

Originally Posted by skiingwiz

It would be nice (in my opinion) if STVi plugins could be configured from within the the plugin manager like General plugins can.

Sure, that's the logical place to do it from a UI perspective. My point is that we don't need to wait for the Sage devs to implement that UI framework, since it's all just Studio code. We can do it ourselves with a shared STVI that extends the existing config UI to work with config data from STVI plugins (be it through XML or some other mechanism).

[skiingwiz]

Originally Posted by GKusnick

Sure, that's the logical place to do it from a UI perspective. My point is that we don't need to wait for the Sage devs to implement that UI framework, since it's all just Studio code. We can do it ourselves with a shared STVI that extends the existing config UI to work with config data from STVI plugins (be it through XML or some other mechanism).

I agree with you and think that it's a good idea. (I was trying to add to your point)