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
New Versions of InputDeviceMapper of LiveDriveIR
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="kaburke" data-source="post: 12081" data-attributes="member: 11818"><p>Thanks for you feedback; I appreciate you taking the time to try the plugins, and even put them to use.</p><p></p><p></p><p>Good idea. It will be done in InputDeviceMappings v0.3.</p><p></p><p></p><p>This is certainly something I'll consider, but seeing as the only part of InputDeviceMapper that the device plugins "see" are the interfaces and the handle() method, they are isolated from any internal changes. From now on I am going to make a point not to change the interfaces or handle() method definitions, nor to place more responsibility for anything on the device plugins, in order to ensure backward compatibility. Having said that, if ever I decide I have to make such a change, I will of course have to implement some form of versioning.</p><p></p><p></p><p>The testing area is an interesting idea. It would actually have simplified my development if I hadn't had to keep fliping back to MediaPortal to test the mappings! I will try to develop something along those lines, though I'm not entirely clear yet how the testing would work (simply printing out the mapped Action or keystroke seems pedantic, but may be sufficient).</p><p></p><p>As to selecting a Device Plugin first and grouping all mappings in a per Device manner, I purposely did not do that. I thought it could be useful to have a Profile that could contain mappings from several different Device Plugins (e.g., a Profile that allows you to use both a gamepad and a remote at the same time - perhaps the remote when you're in the living room and the gamepad when you're sitting at your computer).</p><p></p><p></p><p>I agree. I was bothering me, too, but I rationalized it away by saying that, usually, this would only be a one-time-setup. Once you have the mappings configured (a matter of say an hour or whatever), you're not likely to go back and redo it ever again - indeed you probably won't ever come back to the config screen. But, seeing as you pointed it out, I guess I shouldn't have been lazy, and done something about it.</p><p></p><p>In InputDeviceMappings v0.3, if the Name field is left blank, I will generate a Name. (Incidentally, in InputDeviceMappings v0.2 there wasn't anything stopping you from leaving the Name field blank - your mapping simply wouldn't have had a name.)</p><p></p><p></p><p>I'm not quite sure what you mean, so I'll take a look at your WinLirc AddOn. I agree that learning the actions one at a time is quite tedious, so any ideas on improving that process are welcome. As I said, I'll have a look at your AddOn and see what I come up with.</p><p></p><p></p><p>My apologies. It's rather embarassing that I missed such a simple bug. It's fixed in InputDeviceMappings v0.3.</p><p></p><p>Incidentally, I'm going to post InputDeviceMappings v0.3 in the usual spot in about 30-60 minutes, once I have it packaged and the documents updated.</p><p></p><p>InputDeviceMappings v0.3 has been uploaded as a patch: <a href="http://sourceforge.net/tracker/index.php?func=detail&aid=1159130&group_id=107397&atid=647927" target="_blank">InputDeviceMapper</a></p></blockquote><p></p>
[QUOTE="kaburke, post: 12081, member: 11818"] Thanks for you feedback; I appreciate you taking the time to try the plugins, and even put them to use. Good idea. It will be done in InputDeviceMappings v0.3. This is certainly something I'll consider, but seeing as the only part of InputDeviceMapper that the device plugins "see" are the interfaces and the handle() method, they are isolated from any internal changes. From now on I am going to make a point not to change the interfaces or handle() method definitions, nor to place more responsibility for anything on the device plugins, in order to ensure backward compatibility. Having said that, if ever I decide I have to make such a change, I will of course have to implement some form of versioning. The testing area is an interesting idea. It would actually have simplified my development if I hadn't had to keep fliping back to MediaPortal to test the mappings! I will try to develop something along those lines, though I'm not entirely clear yet how the testing would work (simply printing out the mapped Action or keystroke seems pedantic, but may be sufficient). As to selecting a Device Plugin first and grouping all mappings in a per Device manner, I purposely did not do that. I thought it could be useful to have a Profile that could contain mappings from several different Device Plugins (e.g., a Profile that allows you to use both a gamepad and a remote at the same time - perhaps the remote when you're in the living room and the gamepad when you're sitting at your computer). I agree. I was bothering me, too, but I rationalized it away by saying that, usually, this would only be a one-time-setup. Once you have the mappings configured (a matter of say an hour or whatever), you're not likely to go back and redo it ever again - indeed you probably won't ever come back to the config screen. But, seeing as you pointed it out, I guess I shouldn't have been lazy, and done something about it. In InputDeviceMappings v0.3, if the Name field is left blank, I will generate a Name. (Incidentally, in InputDeviceMappings v0.2 there wasn't anything stopping you from leaving the Name field blank - your mapping simply wouldn't have had a name.) I'm not quite sure what you mean, so I'll take a look at your WinLirc AddOn. I agree that learning the actions one at a time is quite tedious, so any ideas on improving that process are welcome. As I said, I'll have a look at your AddOn and see what I come up with. My apologies. It's rather embarassing that I missed such a simple bug. It's fixed in InputDeviceMappings v0.3. Incidentally, I'm going to post InputDeviceMappings v0.3 in the usual spot in about 30-60 minutes, once I have it packaged and the documents updated. InputDeviceMappings v0.3 has been uploaded as a patch: [url=http://sourceforge.net/tracker/index.php?func=detail&aid=1159130&group_id=107397&atid=647927]InputDeviceMapper[/url] [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Plugins
New Versions of InputDeviceMapper of LiveDriveIR
Contact us
RSS
Top
Bottom