Reply to thread

Message

In answer to your first question (static pointer), that would be nice, but the application instantiates the other plugins (e.g., LiveDriveIR, etc.) independantly of InputDeviceMapper, so how would I get a handle to it to store it in the first place?

Having said that, your second question is quite interesting, and negates the first (sort of). The idea of making the plugins separate from the built-in plugin system strikes me as a good one. Indeed, short of anyone pointing out any reasons why that would be a bad idea, I am going to go ahead and implement it.

One final note, not to be nitpicky, but I don't want the InputDeviceMapper to be restricted by misconceptions: the device plugins (e.g., LiveDriveIR, etc.) need not be IR plugins. They could be gameport plugins, keyboard plugins, etc.

(I apologize if you understood that already - as I said, I just don't want others getting the wrong impression, and thereby limit the potential usefulness of InputDeviceMapper.)

<blockquote data-quote="kaburke" data-source="post: 11971" data-attributes="member: 11818">In answer to your first question (static pointer), that would be nice, but the application instantiates the other plugins (e.g., LiveDriveIR, etc.) independantly of InputDeviceMapper, so how would I get a handle to it to store it in the first place?Having said that, your second question is quite interesting, and negates the first (sort of). The idea of making the plugins separate from the built-in plugin system strikes me as a good one. Indeed, short of anyone pointing out any reasons why that would be a bad idea, I am going to go ahead and implement it.One final note, not to be nitpicky, but I don't want the InputDeviceMapper to be restricted by misconceptions: the device plugins (e.g., LiveDriveIR, etc.) need not be IR plugins. They could be gameport plugins, keyboard plugins, etc.(I apologize if you understood that already - as I said, I just don't want others getting the wrong impression, and thereby limit the potential usefulness of InputDeviceMapper.)</blockquote>

[QUOTE="kaburke, post: 11971, member: 11818"] In answer to your first question (static pointer), that would be nice, but the application instantiates the other plugins (e.g., LiveDriveIR, etc.) independantly of InputDeviceMapper, so how would I get a handle to it to store it in the first place? Having said that, your second question is quite interesting, and negates the first (sort of). The idea of making the plugins separate from the built-in plugin system strikes me as a good one. Indeed, short of anyone pointing out any reasons why that would be a bad idea, I am going to go ahead and implement it. One final note, not to be nitpicky, but I don't want the InputDeviceMapper to be restricted by misconceptions: the device plugins (e.g., LiveDriveIR, etc.) need not be IR plugins. They could be gameport plugins, keyboard plugins, etc. (I apologize if you understood that already - as I said, I just don't want others getting the wrong impression, and thereby limit the potential usefulness of InputDeviceMapper.) [/QUOTE]