A
Anonymous
Guest
(Hmz, is this the correct forum to post such 'requests' in? I am having doubts..., grtz: PV)
Okthen, i haven't read all postings but i would like to post my two europennies also so here it goes...
A solid plugin interface with strong boundaries between the core and plugins should be defined. This is imho very important to prevent future trouble. MediaPortal has its layout and functionality nicely separated. I think that this strategy should be handled for plugins. As far as i can see a plugin will most of the time be a combination of some layout xml files and the required images etc., some plugin specific code and a configuration 'interface'. (by the way, i hope it isn't too much in detail for this topic..)
HMI plugin interface
A plugin interface where users can choose which input device to use, and can write their own for exotic devices.
Plugin related configuration contained within the plugin assemblies
... and dynamic loaded and displayed within the settings window. (i guess that this should not be that difficult; scan plugin files for embedded configuration interfaces. These interfaces deliver ContainerControl which the settings window can show)
An intelligent installer.
I think allot of people will not start using home theater software for the sole fact that it can be quit a pain-in-the-a$$ to configure (Everybody understands that i ofcourse point the finger to other home theater applications
). The userbase could be extended quite allot if the installation of MediaPortal gave the user the ability to tweak it to their own settings. Ask what skin a user wants to use, if he wants to use it for tv, what kind of HMI (remote etc) he wants to use, detect capturecards automatic and let the user verify and possibly modify them, what kind of buttons he wants on his homepage. I would like to see that the installer asked me if i would to use the tvguide, and if so from within what country. I do not now exactly what can and cannot be done in relation to xmltv but it sure would boost 'attractiveness' (spelling?).
Skin editor.
I do not know if all skinning is done by hand, i guess there will be allot of tools written for XBMC that sure come in handy when writing a skin for MediaPortal. If this would not be the case then i think a skineditor would be a nice addition. Using C# and System.Windows.Forms a bit 'different' than normal one could write a skin editor without much hassle. Using controls as placeholders (and display) images and buttons would enable editors to move, resize and set the z-order of skin elements with ease. Using .NET's property viewer the rest of each GuiControl based element could be displayed (and modified) in an elegant way. After creating a fancy skin one press of a button generates a xml file containing all relevant data.
Wowza! :shock:
enough text for now, i am going to get a cold glass of.........
I hope it's not written too fuzzy, and these things are only opinions: there can be dozens of reasons to do things very differently....
Greetings,
Peter Vrenken @ Feedback is a good thing...
Okthen, i haven't read all postings but i would like to post my two europennies also so here it goes...
A solid plugin interface with strong boundaries between the core and plugins should be defined. This is imho very important to prevent future trouble. MediaPortal has its layout and functionality nicely separated. I think that this strategy should be handled for plugins. As far as i can see a plugin will most of the time be a combination of some layout xml files and the required images etc., some plugin specific code and a configuration 'interface'. (by the way, i hope it isn't too much in detail for this topic..)
HMI plugin interface
A plugin interface where users can choose which input device to use, and can write their own for exotic devices.
Plugin related configuration contained within the plugin assemblies
... and dynamic loaded and displayed within the settings window. (i guess that this should not be that difficult; scan plugin files for embedded configuration interfaces. These interfaces deliver ContainerControl which the settings window can show)
An intelligent installer.
I think allot of people will not start using home theater software for the sole fact that it can be quit a pain-in-the-a$$ to configure (Everybody understands that i ofcourse point the finger to other home theater applications
). The userbase could be extended quite allot if the installation of MediaPortal gave the user the ability to tweak it to their own settings. Ask what skin a user wants to use, if he wants to use it for tv, what kind of HMI (remote etc) he wants to use, detect capturecards automatic and let the user verify and possibly modify them, what kind of buttons he wants on his homepage. I would like to see that the installer asked me if i would to use the tvguide, and if so from within what country. I do not now exactly what can and cannot be done in relation to xmltv but it sure would boost 'attractiveness' (spelling?).Skin editor.
I do not know if all skinning is done by hand, i guess there will be allot of tools written for XBMC that sure come in handy when writing a skin for MediaPortal. If this would not be the case then i think a skineditor would be a nice addition. Using C# and System.Windows.Forms a bit 'different' than normal one could write a skin editor without much hassle. Using controls as placeholders (and display) images and buttons would enable editors to move, resize and set the z-order of skin elements with ease. Using .NET's property viewer the rest of each GuiControl based element could be displayed (and modified) in an elegant way. After creating a fancy skin one press of a button generates a xml file containing all relevant data.
Wowza! :shock:
enough text for now, i am going to get a cold glass of.........
I hope it's not written too fuzzy, and these things are only opinions: there can be dozens of reasons to do things very differently....
Greetings,
Peter Vrenken @ Feedback is a good thing...