Italy
While speaking of skins.
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'm totally with tourettes.
Every plugin *must* include skin files for the default skins (nowr B3 and B3Wide). This should be the first requirement needed to include plugin in the official repository.
The future of MPI - we need your opinion! (5 Viewers)
- Thread starter infinite.loop
- Start date
- Thread starter
- #62
I am preparing a news entry right now.
we are using the opensource remository on our homepage
we want to:
- take its current svn sourcecode and work from that (create "our" repository)
- add new features:
- versioning - a skin for example just has one entry in the repository, which gets upated. in the entry you can see old versions, and changelog. right now you can see that developers and skinners create a new entry for every version they release. this makes automated updates inside the MPI-application impossible, because it can not check one entry for updates
- create new "views" i.e. "Top 10 skins", "Most downloaded Skins", etc. this should help to make them more popular
- improve the "update" process for those which store extensions in our repository
- more smaller changes / features
- improove the look and feel of the online repository intselfe.
So as you can see, we do not only need an skilled wev-developer, but also one which is willing to donate quite a big amount of sparetime (like every other team member does
).We tried to get web-developers into the team for more then one year now. Besides of "many words and hot air" we never received anything working.
btw. i guess that some are about to write "then use an other repository" or "create your own".
remository is a very good and stable software. creating a new one from scratch is hopeless because it requires A LOT of time, experience and many web-developers (which we do not have
).We were also looking at many other repositories during the last year (including OpenMaid), but none of them is "better" then what we have right now. And all need to be changed to get the features in we want.
also agree for me to that @ cybertex...
it is an absolut "need" that the default skins should be supported.
it is an absolut "need" that the default skins should be supported.
- Thread starter
- #64
I totally agreed that the manual is a big problem. Sadly writing manuals is not very popular (not even among community plugin devs. )
I will try to get some free time to rework the manual of it in the wiki, and update with features we will add.
But then again, we want to focus on MP2, and not start to re-creating one after the other feature of MP1.
As you can see we try to make a balancing act between maintaining and improving MediaPortal 1 and not shifting all our development power back to MP1.
This is why i think that button which opens the MP-Extensionsinstaller, should be done for MP1.
In MP2 we will integrate MPE into the configuration application from the start.
)I will try to get some free time to rework the manual of it in the wiki, and update with features we will add.
Indeed, the whole configuration application should be re-created from scratch.
But then again, we want to focus on MP2, and not start to re-creating one after the other feature of MP1.
As you can see we try to make a balancing act between maintaining and improving MediaPortal 1 and not shifting all our development power back to MP1.
This is why i think that button which opens the MP-Extensionsinstaller, should be done for MP1.
In MP2 we will integrate MPE into the configuration application from the start.
...
This is why i think that button which opens the MP-Extensionsinstaller, should be done for MP1.
In MP2 we will integrate MPE into the configuration application from the start.
and thats a good decision ---
so a good manual (readable by skinner-newbees like me) for MPI should be also a *must*.
Well, a new button has to be added to the deploy tool. It will link to the downloadmanager. Next to 'Close' It should say 'Install Plugins' and open the online (prefered by me as you shall know) or offline MPI Downloadmanager. The 'thanks for installation' above should say something about the benefit of plugins and also tell that MP works just fine without them.
Sorry to hear the MP is having so much trouble finding a webdeveloper. I hope it will change in the near future. Also my apologies for my language in the previous post.
- Moderator
- #67
I understand, and you make an excellent point. On the same thread of reasoning, you guys should consider features that will work for MP2 MPIs and not MP1 MPIs. I cant think of any specific example (probably mainly because I am not too familiar with MP2) but it seems to me like there is a lot that could be reused between the two systems. Now might be a good time to sit down with the people nose deep in MP2 to get their thoughts on an MPI system and how it could/should interact with MP2. Not necessarily so you can start implemnting these features now, but so that you can code existing changes in a way that wont cause problems later...Indeed, the whole configuration application should be re-created from scratch.
But then again, we want to focus on MP2, and not start to re-creating one after the other feature of MP1.
As you can see we try to make a balancing act between maintaining and improving MediaPortal 1 and not shifting all our development power back to MP1.
This is why i think that button which opens the MP-Extensionsinstaller, should be done for MP1.
In MP2 we will integrate MPE into the configuration application from the start.
Been thinking about this for a while now. My view is that Skin choice should definately be through MP. This in itself would not be too difficult and you could browse skins and download one you wanted. (it is posible in the current setup to download and change to a skin without closing and restarting MP isn't it???
Plugins however are limited by their interface to MP. It is not simply a case of downloading something, most plugins require quite complex setup and then copying of skin files, ....
It should also be easy enough to identify if skins you have installed have been updated and install new versions. This would not however solve the biggest issue in my opinion which is finding skin files for plugins for your skins (or them existing at all).
This could be solved by combining the skin files with the plugin files but the skin developers seem to (on the whole) be different people to the plugin developers and then you have the issue of who becomes responsible for maintaining the install package for the plugin...
I am begining to think that the best solution might be to keep the split but link them. It would be possible to have a link from a plugin to skin files for that plugin and users could then follow the link to browse skin files (or perhaps the download could include and install the associated skin files that a user selects for that plugin...)
I do however feel fairly strongly that plugins and full skins should be kept seperately for simplicity. The idea of building the skins into the MP client seems to be a winner without too much effort ??? Going to think about this some more on the way home!!!
- Thread starter
- #69
No it is not possible to download and install a skin inside MP and use it without restarting MediaPortal.
This will also not be possible in the future (at least not in MediaPortal 1).
One reason is that the majority of popular community skins also includes plugins they required to work. And MediaPortal is not designed to load/unload new plugins in runtime (nor is configuration.exe).