Bugzilla – Bug 6523
Skin dependent plugin links
Last modified: 2008-01-14 09:52:03 UTC
When a plugin likes to add a link to the home page of the web interface it today uses the Slim::Web::Pages::addPageLinks function, for example like this: Slim::Web::Pages->addPageLinks("browse", { 'PLUGIN_CUSTOMBROWSE' => 'plugins/CustomBrowse/custombrowse_list.html' }); This means that the plugin link will be available on all skins even if the plugin developer hasn't tested it against all skins. It would be great if there was some standard way for a plugin developer to specify which skins the plugin should be available in. For the normal skins this is not a problem, but for special skins like the Nokia770/Touch and the new third party iPeng skin (for the iPhone) it is a problem since these require different skin templates in the plugin to make it look good or even to make it work at all. In the iPeng case me and Joerg has already tested a solution where the plugin registers two pages like this: Slim::Web::Pages->addPageLinks("browse", { 'PLUGIN_CUSTOMBROWSE' => 'plugins/CustomBrowse/custombrowse_list.html' }); Slim::Web::Pages->addPageLinks("browseiPeng", { 'PLUGIN_CUSTOMBROWSE' => 'plugins/CustomBrowse/custombrowse_list.html' }); The iPeng skin has hard coded the SC bundled links from the "browse" context in the skin code, and additionaly also displays the items in the "browseiPeng" category. I'm not sure if this is the best/correct way to do it, but it feels like it would be good to have a way where: 1. Third party plugins can add functionality to the special designed third party skins 2. Third party skins can choose to only show the plugin links that really has been tested with that skin. For the standard skins like default, classic and fishbone they can probably just show the "browse" category contents which should contain all links, but skins like the Nokia770/Touch already today hardcodes what is visible on the first page and can additionally choose to show "browseNokia770" or "browseTouch" if there is space left on the first page.
I don't think we want to get into this kind of thing. skin/plugins should not be this dependent on each other. we really want to be simplifying the api's not making them more complicated. A feature such as this just feel dangerously close to an explosive set of combinations to manage. Plugins should seek to support the baseline EN skin, and all skins should properly support a fallback to EN when specific support may fail. Where the new Default has introduced new features, it should be considered as something we need to port into EN for broad plugin support.
(In reply to comment #1) > Plugins should seek to support the baseline EN skin, and all skins should > properly support a fallback to EN when specific support may fail. Where the new > Default has introduced new features, it should be considered as something we > need to port into EN for broad plugin support. > Agreed, this would be the optimal situation. However, the problem is with the skins that looks quite different from the EN, these has always required skin specific templates in the plugins as far as I've seen both in 6.3, 6.5 and 7.0. The skins I'm thinking of is skins for specific hardware devices, for example the Nokia770 skin and lately also the iPeng third party skin (for the iPhone). Since these skins are adjusted for touch screen devices it could also result in that the interface gets unusable if they fallback to EN. I currently need skin specific templates in my Custom Browse plugin for: - EN - Takes care of classic and fishbone - Default - Takes care of the new default - Nokia770 - Takes care of the Nokia770/Touch skins - iPeng - Takes care of the iPeng skin for the iPhone So I guess I basically agree, the optimal situation would be if plugins only had to bother with EN, although this is currently not the case. This feature request could be closed if we feel that we really is able to provide generic template components so the plugins doesn't need skin specific template code.
Michael thinks we shouldn't fix this.