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: 13569" data-attributes="member: 11818"><p>This is something I have wanted to do for quite a while. Unfortunately, I haven't had the time to dedicate to researching how it would work. I have an "ideal" model, but I am unsure how that model would mesh with MediaPortal in practice.</p><p></p><p>Ideally, all "pages" in MediaPortal would be plugins, preferably with some interface or inheritance parent that is common to all (and unique) to all pages. This, or some form of it, may be how pages are handled in MediaPortal, but, as I said, I haven't had any time to look into it.</p><p></p><p>Assuming that all of the pages were at least plugins (if not plugins with a common/unique ancestor), in config mode InputDeviceMapper would scan the plugins, and allow configurations to be created for each separate page it finds, as well as a "default" configuration. In app mode, when InputDeviceMapper received an event, it would look up the configuration for the active page, and then use that configuration to find the correct Action to send to MediaPortal.</p><p></p><p>Ideally, within the configuration for a given page, one would be able to specify an action on another page (e.g., on my configuration for the Weather Page, the direction and selection buttons may control what weather map I'm looking at, but I can still map the Play/Pause etc. to control my music).</p><p></p><p>Further, it would be ideal if each page defined and exposed it's own actions, rather than all of the pages relying on one common Action group. This way a new page could create complex activities without needing to rely on having an Action created in a global repository.</p><p></p><p>Finally, there could be a global Action repository that can be inherited/used by any page that chooses to do so. This would mean, rather than having separate (for e.g.) PLAY_MUSIC and PLAY_MOVIE actions, there would be a global PLAY action that would behave differently depending on whether or not the music page or video page is active. (This last point could conflict with the previous paragraph, and I'm not entirely convinced of its usefulness. I think I would be inclined to simply rely on the functionality of the previous paragraph and omit the global Action repository idea. I merely mention it here because I have not yet made up my mind.)</p><p></p><p></p><p></p><p>I agree that this functionality would be nice, but I think it is beyond the scope of InputDeviceMapper. InputDeviceMapper only concerns itself with translating Input Device Events into Actions. I believe the "correct" method to implement this feature would be to have a separate plugin for text input that is controlled by Actions, which InputDeviceMapper could certainly pass to it (though, obviously, not necessarily).</p><p></p><p></p><p></p><p>I have been meaning to change my model for the handle() method. The change would have no external affect (no plugins would have to change), and there would not be any difference in functionality, but I think the change would prevent the above error. It seems that the error isn't in InputDeviceMapper or any plugin, but I do think my (pending) modification would eliminate the case that creates this error. I am busy for the next little while, but I will try to get the change up in the next couple of weeks.</p><p></p><p>Finally, my code is (obviously) open source, so anyone should feel free to change/improve/adapt it as they see fit. All I would ask is that you:</p><p></p><ul> <li data-xf-list-type="ul">1) keep any new incarnations of InputDeviceMapper compatible with existing Input Device Plugins<br /> 2) <strong>if possible</strong>, not create an incarnation that allows Input Device Plugins that are incompatible with the original InputDeviceMapper<br /> 3) create a new code "tree" for any new incarnations (i.e., don't create a new InputDeviceMapper and call it InputDeviceMapper v1.0 - rename it to reflect your change - e.g., InputDevicePageMapper). I may at some point decide to incorporate an alternate incarnation into the "main" branch, but I don't want to get into any code/version confusions.</li> </ul><p></p><p>Please feel free to comment/question/respond to my ideas as expressed in this post.</p></blockquote><p></p>
[QUOTE="kaburke, post: 13569, member: 11818"] This is something I have wanted to do for quite a while. Unfortunately, I haven't had the time to dedicate to researching how it would work. I have an "ideal" model, but I am unsure how that model would mesh with MediaPortal in practice. Ideally, all "pages" in MediaPortal would be plugins, preferably with some interface or inheritance parent that is common to all (and unique) to all pages. This, or some form of it, may be how pages are handled in MediaPortal, but, as I said, I haven't had any time to look into it. Assuming that all of the pages were at least plugins (if not plugins with a common/unique ancestor), in config mode InputDeviceMapper would scan the plugins, and allow configurations to be created for each separate page it finds, as well as a "default" configuration. In app mode, when InputDeviceMapper received an event, it would look up the configuration for the active page, and then use that configuration to find the correct Action to send to MediaPortal. Ideally, within the configuration for a given page, one would be able to specify an action on another page (e.g., on my configuration for the Weather Page, the direction and selection buttons may control what weather map I'm looking at, but I can still map the Play/Pause etc. to control my music). Further, it would be ideal if each page defined and exposed it's own actions, rather than all of the pages relying on one common Action group. This way a new page could create complex activities without needing to rely on having an Action created in a global repository. Finally, there could be a global Action repository that can be inherited/used by any page that chooses to do so. This would mean, rather than having separate (for e.g.) PLAY_MUSIC and PLAY_MOVIE actions, there would be a global PLAY action that would behave differently depending on whether or not the music page or video page is active. (This last point could conflict with the previous paragraph, and I'm not entirely convinced of its usefulness. I think I would be inclined to simply rely on the functionality of the previous paragraph and omit the global Action repository idea. I merely mention it here because I have not yet made up my mind.) I agree that this functionality would be nice, but I think it is beyond the scope of InputDeviceMapper. InputDeviceMapper only concerns itself with translating Input Device Events into Actions. I believe the "correct" method to implement this feature would be to have a separate plugin for text input that is controlled by Actions, which InputDeviceMapper could certainly pass to it (though, obviously, not necessarily). I have been meaning to change my model for the handle() method. The change would have no external affect (no plugins would have to change), and there would not be any difference in functionality, but I think the change would prevent the above error. It seems that the error isn't in InputDeviceMapper or any plugin, but I do think my (pending) modification would eliminate the case that creates this error. I am busy for the next little while, but I will try to get the change up in the next couple of weeks. Finally, my code is (obviously) open source, so anyone should feel free to change/improve/adapt it as they see fit. All I would ask is that you: [list]1) keep any new incarnations of InputDeviceMapper compatible with existing Input Device Plugins 2) [b]if possible[/b], not create an incarnation that allows Input Device Plugins that are incompatible with the original InputDeviceMapper 3) create a new code "tree" for any new incarnations (i.e., don't create a new InputDeviceMapper and call it InputDeviceMapper v1.0 - rename it to reflect your change - e.g., InputDevicePageMapper). I may at some point decide to incorporate an alternate incarnation into the "main" branch, but I don't want to get into any code/version confusions.[/list] Please feel free to comment/question/respond to my ideas as expressed in this post. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Plugins
New Versions of InputDeviceMapper of LiveDriveIR
Contact us
RSS
Top
Bottom
