A simple idea - the Submit file button on the repository page could be changed to open the Create Extension api. The current interface does not even ask Skinners to specify which version of MP their skin supports (or which plugins)
The future of MPI - we need your opinion! (1 Viewer)
- Thread starter infinite.loop
- Start date
- Thread starter
- #32
Thats definitly not a bug.
The plugin developers should add a info to their MPI files about which skins support their plugin.
This info has to be displayed before the installation starts.
While speaking of skins.
We are very, very sad that the majority of plugin developers completelly ignore Blue3 and Blue3wide.
In our opinion, every community plugin should at least include the skinfiles for B3 and B3w.
Well, we could start to use it as one of the criterias when adding plugins to the repository. If default skin is not supported -> not allowed to distribute the plugin within official ways. I don't know why that is not already used
- Thread starter
- #34
Personally i do not like to take such steps. But this should be considered.
Well, we could start to use it as one of the criterias when adding plugins to the repository. If default skin is not supported -> not allowed to distribute the plugin within official ways. I don't know why that is not already used
I love this idea!
I'd only add that MP version should be a separate column and that you can sort by column headers (i.e. MP version, rating, #downloads, etc) (when viewing in the list view)
Also, you can't leave it to developers to put the plugins supported or skins supported in the description. That has to be a separate and required field.
In the Extension Manager, could an option be added on the left (where it lists type of extension) for Installed Extensions? So you can quickly see which ones are currently installed and just update those? I know it currently highlights the ones installed with darker text, but you have to wade through a few screens to see them all.
If you can make the MPI look more like the main MP configuration it would feel less like a distant cousin! At least similar visually if not structurally.
Personally i do not like to take such steps. But this should be considered.
Well, we could start to use it as one of the criterias when adding plugins to the repository. If default skin is not supported -> not allowed to distribute the plugin within official ways. I don't know why that is not already used
You could just put a unhappy/bad/scull icon next to the skin in the MPI to indicate that its lacking a blue3 skin file
maybe make the authors feel bad enough to add one 
I don't think the default skin should be supported by ALL plugins - who would be responsible for that to happen? The plugin developer (who suddenly becomes a skin developer too) or the skin designer (the devs in the case f the Blue 3 skins)
The default skin should be FULLY compatible with any plugins it is installed with - beyond that it's up to the user to add/remove/configure as things go on.
Also - I think a poll should be run to see who actually uses the blue skins as a default - in my case it's the first thing I change (I'm in the 'hate Mepoo' camp! Very childish IMHO)
No point worrying about something that might be a minor issue
Unless all possible skins support all the plugins, you are always going to get a situation where a plugin is installed and not compatible with a skin (some of the older, not supported ones don't support either Moving pictures or TVSeries - who would provide the XMLs for them?)
Maybe a better way would be for the MPI installer to search the skins folder and only show the plugins for the skin currently used - then show a warning that changing the skin might break some plugins...
The plugin devs would then need to prvide a list of the supported skin(s).
The default skin should be FULLY compatible with any plugins it is installed with - beyond that it's up to the user to add/remove/configure as things go on.
Also - I think a poll should be run to see who actually uses the blue skins as a default - in my case it's the first thing I change (I'm in the 'hate Mepoo' camp! Very childish IMHO)
No point worrying about something that might be a minor issue
Unless all possible skins support all the plugins, you are always going to get a situation where a plugin is installed and not compatible with a skin (some of the older, not supported ones don't support either Moving pictures or TVSeries - who would provide the XMLs for them?)
Maybe a better way would be for the MPI installer to search the skins folder and only show the plugins for the skin currently used - then show a warning that changing the skin might break some plugins...
The plugin devs would then need to prvide a list of the supported skin(s).
- Thread starter
- #38
Blue3 and Blue3wide are the skins which were shipped with MP.
That community plugins have to support these at least is a logical consequence if you ask me.
It is also in the interest of the users because they do not have to start searching for community skins which support this plugin, if they just want to test it.
Right now, every Blue3 and Blue3wide user is forced to change to a skin he might not like just because it does not even support the shipped skins. This could also mean that other plugins he uses nolonger work because they are not supported in this skin, or the skin contains bugs which the user does not encounter in B3(w).
Adding B3(w) skin support for "every community plugin" into MediaPortal is a stupid idea (we learned form our misstakes in the past).
You just have to compare the release cycles of community plugins and MediaPortal stable releases.
We can not release a new stable build everytime when a new plugin is released.
And on top of that, the only active skin designer we have in the team is harley. who is devinitly not able to create and maintain support for every community plugin.
And creating a basic skin is not a problem for any developer.
That community plugins have to support these at least is a logical consequence if you ask me.
It is also in the interest of the users because they do not have to start searching for community skins which support this plugin, if they just want to test it.
Right now, every Blue3 and Blue3wide user is forced to change to a skin he might not like just because it does not even support the shipped skins. This could also mean that other plugins he uses nolonger work because they are not supported in this skin, or the skin contains bugs which the user does not encounter in B3(w).
Adding B3(w) skin support for "every community plugin" into MediaPortal is a stupid idea (we learned form our misstakes in the past
).You just have to compare the release cycles of community plugins and MediaPortal stable releases.
We can not release a new stable build everytime when a new plugin is released.
And on top of that, the only active skin designer we have in the team is harley. who is devinitly not able to create and maintain support for every community plugin.
And creating a basic skin is not a problem for any developer.
- September 20, 2007
- 109
- 12
- Home Country
-
Netherlands
In my opinion de extension developer does not need to know which skins are installed. He/She must only develop bv. 2 different version for 4x3 and 16x9 that uses his extention. This will then be installed into every skin without those skinfiles.
Skin developers can redesign those files into there own look of the skin.
I am using streamed-mp and it comes with, imo, an exellent installer. The installer also gives you the ability to install plugins that are known to work well with the skin.
What I would like to see is the possibility to install plugins with a skin, depending plugins with another plugin and so on.
To have a generic approach to this, you could create a new section with "packages". A package could be created and documented by anyone, to aid the end user to a perfect setup.
For example, my perfect setup includes a number of plugins, skin and configuration of the windows enviroment.
To help other users accomplish what I perceive as a perfect setup, I could create a package that installs plugins with an additional message from me for each plugin.
What I would like to see is the possibility to install plugins with a skin, depending plugins with another plugin and so on.
To have a generic approach to this, you could create a new section with "packages". A package could be created and documented by anyone, to aid the end user to a perfect setup.
For example, my perfect setup includes a number of plugins, skin and configuration of the windows enviroment.
To help other users accomplish what I perceive as a perfect setup, I could create a package that installs plugins with an additional message from me for each plugin.