Reply to thread

Message

<blockquote data-quote="thlucas" data-source="post: 725522" data-attributes="member: 111098">Hi Yoav - answers to your questions:1) no, I was not familiar with the compatibility requirement as I am fairly new to MP.&nbsp; Sounds like it's a pretty simple process to add the compatibility attributes though.&nbsp; I did run into a problem using the &quot;VirtualKeyboard&quot; control and the &quot;Label&quot; property and &quot;SetLabelAsInitialText&quot; method - they are not supported by MP 1.1.1, so I had to remove that code.&nbsp; Other than that, the plugin has been tested with MP 1.1.1 and 1.2.0 and works fine.&nbsp; I personally run the 1.2.0 version, so that is what I am targeting most of my development for.2) Code is not available for the public currently, though I would not have a problem posting it somewhere.&nbsp; I have not looked into creating an SF account yet, but will soon.&nbsp; In the interim, if you (or anyone) would like the code just send me a PM with your email and I will send it to you.Some more thoughts on Plugin development:1) It would be great if the .XML documentation files (are there any?) were distributed with the MP release.&nbsp; I do not download the MP SVN source, and have been developing my plugins stand-alone.&nbsp; It's a PITA to not have Visual Studio intellisense help when referencing the MP core assemblies, as I have to keep switching to the Wiki docs to see what a property is doing, or jump to Reflector to find other assemblies that use a method or property.&nbsp; 2) what's up with Plugin interfaces that use method syntax instead of property syntax?&nbsp; For example, the &quot;GetID()&quot; method should be a simple property get like &quot;WindowID&quot;, as opposed to a method:string value = this.WindoID;instead of ...string value = this.GetID();3) The plugin examples need to be expanded to include real-world scenarios.&nbsp; The basic one out there now simply shows how to implement the Window interface.&nbsp; It does not show how to open up a dialog window, or open another window / do something / return to the previous window, or even how to load / store settings or trace code execution.&nbsp; And I did not see any examples on how to create a Process plugin from scratch.Other than that, everything is great and I love the MP interface!&nbsp; I worked on a similar media program called XLobby prior to this, and must say that MP beats it hands down - though there are some event-processing type of functions in XLobby that are pretty cool.&nbsp; Other than that, MP is great!Cheers!More thoughts after reading the Plugin compatibility notes ...The &quot;CompatibleVersion&quot; attribute is confusing!&nbsp; Do I list the actual version information as it appears on the MediaPortal.exe?&nbsp; Or do I use the descriptive version?&nbsp; For example, in the docs it says the 1.2.0 Beta = 1.1.7.0 - which do I specify in the attribute value?&nbsp; What about for the 1.1.1 version?&nbsp; It sounds like the developers need to publish a list of MP version constants that they want us to use, as well as keep them updated for future versions.&nbsp; The same goes for the &quot;UsesSubsystem&quot; attribute.I like the idea of compatibility check, but if you're going to enforce it then you need to publish standards and references for developers to follow.</blockquote>

[QUOTE="thlucas, post: 725522, member: 111098"] Hi Yoav - answers to your questions: 1) no, I was not familiar with the compatibility requirement as I am fairly new to MP. Sounds like it's a pretty simple process to add the compatibility attributes though. I did run into a problem using the "VirtualKeyboard" control and the "Label" property and "SetLabelAsInitialText" method - they are not supported by MP 1.1.1, so I had to remove that code. Other than that, the plugin has been tested with MP 1.1.1 and 1.2.0 and works fine. I personally run the 1.2.0 version, so that is what I am targeting most of my development for. 2) Code is not available for the public currently, though I would not have a problem posting it somewhere. I have not looked into creating an SF account yet, but will soon. In the interim, if you (or anyone) would like the code just send me a PM with your email and I will send it to you. Some more thoughts on Plugin development: 1) It would be great if the .XML documentation files (are there any?) were distributed with the MP release. I do not download the MP SVN source, and have been developing my plugins stand-alone. It's a PITA to not have Visual Studio intellisense help when referencing the MP core assemblies, as I have to keep switching to the Wiki docs to see what a property is doing, or jump to Reflector to find other assemblies that use a method or property. 2) what's up with Plugin interfaces that use method syntax instead of property syntax? For example, the "GetID()" method should be a simple property get like "WindowID", as opposed to a method: string value = this.WindoID; instead of ... string value = this.GetID(); 3) The plugin examples need to be expanded to include real-world scenarios. The basic one out there now simply shows how to implement the Window interface. It does not show how to open up a dialog window, or open another window / do something / return to the previous window, or even how to load / store settings or trace code execution. And I did not see any examples on how to create a Process plugin from scratch. Other than that, everything is great and I love the MP interface! I worked on a similar media program called XLobby prior to this, and must say that MP beats it hands down - though there are some event-processing type of functions in XLobby that are pretty cool. Other than that, MP is great! Cheers! More thoughts after reading the Plugin compatibility notes ... The "CompatibleVersion" attribute is confusing! Do I list the actual version information as it appears on the MediaPortal.exe? Or do I use the descriptive version? For example, in the docs it says the 1.2.0 Beta = 1.1.7.0 - which do I specify in the attribute value? What about for the 1.1.1 version? It sounds like the developers need to publish a list of MP version constants that they want us to use, as well as keep them updated for future versions. The same goes for the "UsesSubsystem" attribute. I like the idea of compatibility check, but if you're going to enforce it then you need to publish standards and references for developers to follow. [/QUOTE]

Verification