Bugzilla – Bug 2403
Descriptive plugin text
Last modified: 2008-12-15 13:07:08 UTC
With the proliferation of plugins (14 in 6.5b), I think it would be nice if the puppies could expose some descriptive text in the list: Home / Server Settings / Plugins. While the standard name is probably descriptive enough for us, let's not forget about the new user which may not now "MusicMagic" is a side product and that the plugin is just an interface to it (like is iTunes). At the very least, I think plug in names should include a functional term (like interface, game, screensaver, etc). If a descriptive text is provided, then it should point out what configuration, if any, the plugin allows and where to find it (f.e. "If enabled, the iTunes plugin can be configured from the iTunes preference tab").
Sounds good to me.
kdf, may I humbly request your help on this one? Adding a function to plugins so that they return the text is easy. The complex part is Setup.pm and the html and skins. I get as far as semi-decyphering the plugin display name is acquired by the sub defined for 'externalValue' but then this is mapped to a label in the HTML. How do I add another value there? A second label? How do I get the Setup machine to digest that? I thought about hardcoding a <BR> but the skin Gods are going to hang me dry... While we're at it, I would like plugins to be able to have a link to some help in HTML (that is located in the plugin directory). I guess "routing" the HTML is sorted out, but adding the link again is difficult for me. I am thinking of something that could look like below, but this is just a suggestion: CB DisplayName of plugin1 <Help link for plugin1> Bla bla this plugin1 does wonderful things CB DisplayName of plugin2 <Help link for plugin2> Plugin2 is even more wonderful The logic for the help link is threefold: first today the CLI API is a plugin but its help is in the server depth. The above sounds to me more "logical". Second if we want plugins to expose CLI commands, there must be a way to document them and this sounds like a good way to me. Third, by keeping plugin and doc together we potentially increase the chance of the doc being read/updated at the same time the plugin is enabled/changed, respectively.
I'm more than happy to help, but I would hold off for now. Dan is working on some samples for me for some major setup rework. This will likely tear apart the whole setup hash structure, validation, plugin api and settings pages. I'm hoping it will appear soon since I'm holding onto my own experimental code that Dan didn't like (in case any of it is usable) Hopefully I'll have enough time in the remainder of this week to bang out any remaining leg work (assuming Dan isn't doing all of it as we speak).
Take your time. It's not urgent. Thanks.
Setup work isn't going to happen for 6.5 (as much as I would like it too). We are feature complete, and are just fixing bugs at this point.
I think this can be closed; it's fixed in 7.0
This bug appears to have been fixed in the latest release! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look. Make sure to include the version number of the software you are seeing the error with.