home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
MediaPortal 1 Plugins
Plugin interface
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Anonymous" data-source="post: 440"><p>Hello,</p><p></p><p>first of all a big compliment to all the people that have donated some (i guess allot of) spare time to develop MediaPortal; it looks and feels like an application that has a promising future ahead... </p><p></p><p>At this moment i am reading through the sources in order to start implementing my first plugin. I am a proud owner of a MSI MEGA 180 and want to use MediaPortal on it as interface for my home theater. The plugin i want to develop (i haven't got much spare time so it will take me a while) will enable users to interface with their radiotuners. In my case this would be the MEGA 180's tuner, but such a plugin should be written so that other people could use their tuners also. </p><p></p><p>The problem i am having is how such a plugin should be implemented. In my opinion a plugin should contain the code that is related to the plugin, except code that is common to allot of modules in the application. I can be wrong and do not want to be annoying but if i interpreted the sources correctly, the code that is related to the configuration of a plugin (like the weather plugin) is not contained into the plugin itself.</p><p></p><p>May i be so inpolite to ask why this is done? i know that it is quite simple to also implement the configuration interface within the related plugin. I do not know if this could be possible with MediaPortal but i guess it is something to keep in mind when looking at the big picture. When allot of people start to implement plugins for MediaPortal it is not an option to recompile the core each time; i guess this could lead to conflicts within the software. </p><p>In the ideal situation a plugin would consist of one or more Assemblies with one or more related layout XML files and images etc. and should get registered somehow. </p><p></p><p>I think that imho the boundaries between the core and plugins should be a bit less fuzzy. </p><p></p><p>Please forgive me if a wrote allot of noncense above, i am only trying to help become MediaPortal even better.</p><p></p><p>Feedback is welcome!</p><p></p><p>Greetings,</p><p></p><p>Peter Vrenken @ sittin' with his laptop on the balkony in the sunny Netherlands...</p></blockquote><p></p>
[QUOTE="Anonymous, post: 440"] Hello, first of all a big compliment to all the people that have donated some (i guess allot of) spare time to develop MediaPortal; it looks and feels like an application that has a promising future ahead... At this moment i am reading through the sources in order to start implementing my first plugin. I am a proud owner of a MSI MEGA 180 and want to use MediaPortal on it as interface for my home theater. The plugin i want to develop (i haven't got much spare time so it will take me a while) will enable users to interface with their radiotuners. In my case this would be the MEGA 180's tuner, but such a plugin should be written so that other people could use their tuners also. The problem i am having is how such a plugin should be implemented. In my opinion a plugin should contain the code that is related to the plugin, except code that is common to allot of modules in the application. I can be wrong and do not want to be annoying but if i interpreted the sources correctly, the code that is related to the configuration of a plugin (like the weather plugin) is not contained into the plugin itself. May i be so inpolite to ask why this is done? i know that it is quite simple to also implement the configuration interface within the related plugin. I do not know if this could be possible with MediaPortal but i guess it is something to keep in mind when looking at the big picture. When allot of people start to implement plugins for MediaPortal it is not an option to recompile the core each time; i guess this could lead to conflicts within the software. In the ideal situation a plugin would consist of one or more Assemblies with one or more related layout XML files and images etc. and should get registered somehow. I think that imho the boundaries between the core and plugins should be a bit less fuzzy. Please forgive me if a wrote allot of noncense above, i am only trying to help become MediaPortal even better. Feedback is welcome! Greetings, Peter Vrenken @ sittin' with his laptop on the balkony in the sunny Netherlands... [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Plugins
Plugin interface
Contact us
RSS
Top
Bottom