- Moderator
- #71
*It would be a good idea to introduce the notion of 'Shared' and a 'Permanent' Feature/Component when setting up a project.
Lets take an example of two plugins sharing the same file(s), it would be desirable to ensure that the component is set to 'Shared' and increment a reference counter each time the file is installed and decremented when its uninstalled. When the Counter is set to 1 before the uninstall then its safe to remove.
For 'Permanent' I think files such as 'System Fonts' should be marked as 'Permanent and/or the ability to customize which you think should be.
* Ability to launch Pre/Post Build scripts (Even better would be a built in scripting engine). A Repository could be created which contain useful functions, these could then be imported into the script for use.
* Ability to create Simple Custom Dialogs, you could allow just a handful of controls (textbox, listbox, combobox, radiooption and button). These could map to Features/Components or properties that can be used in post build scripts e.g.
Two radio buttons could map to: TVGuide (8 Rows) & TVGuide (12 Rows)
* Store Path Variables for the project, these would hold the location of the source files mapping to your components. e.g.
%SKINFILES% = D:\Development\MediaPortal\Skins\StreamedMP
%PLUGINS% = D:\Development\MediaPortal\Plugins
When adding files to the project, if the files exist in one of your Path Variables then it will use this path to define its location:
%SKINFILES%\*.xml
%PLUGINS%\trunk\MP-TVSeries\Bin\Release\MP-TVSeries.dll
%PLUGINS%\trunk\MovingPictures\Bin\Release\MovingPictures.dll
The advantage of this is that any developer can open your MPI project, setup their Path Variables and do a build.
* Ability to create Shortcuts on the Desktop/MediaPortal programs menu e.g. a Help File or link to online location of Help. This would save the user hunting for it at a later date if required.
* Suggested way of adding content to the MPI package:
First have a list of Pre-Defined Folders that can be used e.g.
SkinFolder
PluginsFolder
FontsFolder
Then the developer adds components and or additional sub-folders under each Folder:
SkinFolder
|-----xmlSkinFiles
|-----images
PluginsFolder
|-----\Windows\tvSeries
|-----\Windows\movingPics
|-----\Process\rss
FontsFolder
|-----fonts
Each component defined e.g. xmlSkinFiles would have options to add a File, Dynamic List of Files or an Exclusion List
This should be repeatable such that for each component you can add several single files plus a bunch of files of a particular file type.
You could use an Exclusion List to filter out files that you may want to separate into multiple components for feature selection e.g. multiple tvguides
The next thing that the developer would do is map all the components to a particular feature, this is so the end user can control what is going to be installed
Main (*Required/Invisible*)
|----xmlSkinFiles
|----Images
|----fonts
|----TVGUIDE8ROWS\tvguide8Rows
|----TVGUIDE12ROWS\tvguide12Rows
Plugins
|----Moving Pictures\movingPics
|----TVSeries\tvSeries
etc
All the end user would need to see is a Tree View of the Feature Names (the components would not be visible e.g. xmlSkinFiles, fonts).
The Features should have the ability to be marked as 'Required' such that it can't be removed during User Feature selection in the Install Sequence. Or you can mark as Invisible such that it cant even be seen for selection.
Features/Components are a great way to control what will get installed. I know this is a big one and probably asking too much
Lets take an example of two plugins sharing the same file(s), it would be desirable to ensure that the component is set to 'Shared' and increment a reference counter each time the file is installed and decremented when its uninstalled. When the Counter is set to 1 before the uninstall then its safe to remove.
For 'Permanent' I think files such as 'System Fonts' should be marked as 'Permanent and/or the ability to customize which you think should be.
* Ability to launch Pre/Post Build scripts (Even better would be a built in scripting engine). A Repository could be created which contain useful functions, these could then be imported into the script for use.
* Ability to create Simple Custom Dialogs, you could allow just a handful of controls (textbox, listbox, combobox, radiooption and button). These could map to Features/Components or properties that can be used in post build scripts e.g.
Two radio buttons could map to: TVGuide (8 Rows) & TVGuide (12 Rows)
* Store Path Variables for the project, these would hold the location of the source files mapping to your components. e.g.
%SKINFILES% = D:\Development\MediaPortal\Skins\StreamedMP
%PLUGINS% = D:\Development\MediaPortal\Plugins
When adding files to the project, if the files exist in one of your Path Variables then it will use this path to define its location:
%SKINFILES%\*.xml
%PLUGINS%\trunk\MP-TVSeries\Bin\Release\MP-TVSeries.dll
%PLUGINS%\trunk\MovingPictures\Bin\Release\MovingPictures.dll
The advantage of this is that any developer can open your MPI project, setup their Path Variables and do a build.
* Ability to create Shortcuts on the Desktop/MediaPortal programs menu e.g. a Help File or link to online location of Help. This would save the user hunting for it at a later date if required.
* Suggested way of adding content to the MPI package:
First have a list of Pre-Defined Folders that can be used e.g.
SkinFolder
PluginsFolder
FontsFolder
Then the developer adds components and or additional sub-folders under each Folder:
SkinFolder
|-----xmlSkinFiles
|-----images
PluginsFolder
|-----\Windows\tvSeries
|-----\Windows\movingPics
|-----\Process\rss
FontsFolder
|-----fonts
Each component defined e.g. xmlSkinFiles would have options to add a File, Dynamic List of Files or an Exclusion List
This should be repeatable such that for each component you can add several single files plus a bunch of files of a particular file type.
You could use an Exclusion List to filter out files that you may want to separate into multiple components for feature selection e.g. multiple tvguides
The next thing that the developer would do is map all the components to a particular feature, this is so the end user can control what is going to be installed
Main (*Required/Invisible*)
|----xmlSkinFiles
|----Images
|----fonts
|----TVGUIDE8ROWS\tvguide8Rows
|----TVGUIDE12ROWS\tvguide12Rows
Plugins
|----Moving Pictures\movingPics
|----TVSeries\tvSeries
etc
All the end user would need to see is a Tree View of the Feature Names (the components would not be visible e.g. xmlSkinFiles, fonts).
The Features should have the ability to be marked as 'Required' such that it can't be removed during User Feature selection in the Install Sequence. Or you can mark as Invisible such that it cant even be seen for selection.
Features/Components are a great way to control what will get installed. I know this is a big one and probably asking too much