The future of MPI - we need your opinion! (1 Viewer)

[cheezey]

Well, I was trying not to be THAT obvious but yes, link to WIKI page or provide equivalent documentation. Although I would prefer the Wiki as it can be kept updated (rather than static documentation like a readme) It also ensures a common location and format for users to access ALL documentation. No doubt that was the original intent, it is just not being used.

The WIKI is a bit of a pain to use though - the GUI editor frequently screws up formatting leaving you to edit by text - but then you have to use all sorts of string combinations for formatting. I have a wiki for the iPiMP plugin but the install instructions are a PDF exported from MS Word 'cos it was a whole lot easier to write it in that.

How would MPI cope with the iPiMP 'add-on' - it consists of an MP process plugin, a TV server plugin, apache web server and other utilities. I currently use NSIS with about 20 custom dialogs to build the installer.

 

[mcraenz]

Sorry if it's already been mentioned this thread but the reason I didn't use MPI for my MyPowerControl plug-in was because it needs to install a windows service; so I used MSI. From memory MPI didn't even support pre-run / post-run script. it was some time ago though. For the record I'll be happy to convert my plug-in to MPI as longs as it supports the features I require.

 

[infinite.loop]

one thing I don't think is listed yet are dependencies.
Some plugins depend on others which you have to install before installing the other.
The MPI application could automatically install those dependencies (if the user agrees, of course).

Thats a good idea, but this will mean that we have to do quite big changes to our current repository.
And as you might have read, we have big troubles finding dedicated web-developers.

Nevertheless i will put this on the wishlist.

 

[fforde]

Plan big and worry about implementation later. If you come up with a compelling design, developers will come.

 

[infinite.loop]

Well, I was trying not to be THAT obvious but yes, link to WIKI page or provide equivalent documentation. Although I would prefer the Wiki as it can be kept updated (rather than static documentation like a readme) It also ensures a common location and format for users to access ALL documentation. No doubt that was the original intent, it is just not being used.

The WIKI is a bit of a pain to use though - the GUI editor frequently screws up formatting leaving you to edit by text - but then you have to use all sorts of string combinations for formatting. I have a wiki for the iPiMP plugin but the install instructions are a PDF exported from MS Word 'cos it was a whole lot easier to write it in that.

for a start you could just copy/paste that into a wiki page.

noone demands perfectly styled wiki pages.

How would MPI cope with the iPiMP 'add-on' - it consists of an MP process plugin, a TV server plugin, apache web server and other utilities. I currently use NSIS with about 20 custom dialogs to build the installer.

this indeed is a problem, MPI will not be able to adress this case in MediaPortal 1.

the reason is that TV-Server is not "supported", and i am not sure if we can add it (in MediaPortal 1).

In MediaPortal 2, we do not have this problem anymore.

what me might could still do is add a "special section" for these plugins inside the MPI application.
So the user will still "find" these plugins when browsing the list inside MPI.
The description should then tell the user that he has to "manually" install this extension.
So you just upload your extension to the repository on the homepage (no MPI), but users will see it when browsing the list of extensions inside MPI.
This will not make the installation easier for the end-user, but might draw more attention to you extension then and allows to browse "all extensions" in one application.

 

[RCW]

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)

Don't take this the wrong way SpudR but.....Mepo childish??? What about your avatar!


I use the default Blue skin because of the lack of clarity on what other skins are fully compatable with 1.0.0.0. Sorting out skins /plugins would be great.

I used to use BlackMyst with 0.2.3 but my system is working great at the moment and I don't want to mess with it for some eye candy.

Great work by all at MP - a great piece of software and much appreciated.

 

[NielsSF]

I do think that when we start working on the MPI we need it to make it so that it can be used for MPI as for MPII.
Also it must be used for the client and the TV-server.

But one question i came up is, why do we want to make a new installer programm when there are some very good ones are around. Also some good opensource version, which best can be forked to be a used for this job.

 

[infinite.loop]

I do think that when we start working on the MPI we need it to make it so that it can be used for MPI as for MPII.
Also it must be used for the client and the TV-server.

TV-Server support for MPI in MediaPortal 1 will mostelikely not happen.
as i said, in MediaPortal 2, this limitation does/will not apply.

But one question i came up is, why do we want to make a new installer programm when there are some very good ones are around. Also some good opensource version, which best can be forked to be a used for this job.

Do you have one in mind?

 

[fforde]

But one question i came up is, why do we want to make a new installer programm when there are some very good ones are around. Also some good opensource version, which best can be forked to be a used for this job.

Do you have one in mind?

He makes a good point. Maybe we could just use NSIS. It is open source and has an extensible architecture (you can create plug-ins for NSIS) so maybe it would be a good idea to use that with a MediaPortal specific NSIS plug-in to fullfill any app specific needs we have (if there are any that are not covered by NSIS).

We could have a template project so they all look sort of the same and maybe even a set of guidelines of how an install app for a plug-in/skin should look and behave.

 

[infinite.loop]

But one question i came up is, why do we want to make a new installer programm when there are some very good ones are around. Also some good opensource version, which best can be forked to be a used for this job.

Do you have one in mind?

He makes a good point. Maybe we could just use NSIS. It is open source and has an extensible architecture (you can create plug-ins for NSIS) so maybe it would be a good idea to use that with a MediaPortal specific NSIS plug-in to fullfill any app specific needs we have (if there are any that are not covered by NSIS).

We could have a template project so they all look sort of the same and maybe even a set of guidelines of how an install app for a plug-in/skin should look and behave.

As far as i know there is no good GUI editor for creating an NSIS installer.
So this would be a big step backwards compared to current MPI.

also creating those "complex" installers which was talked about in here will not be easier for the average skinner when using NSIS.