Fri, 30 Jan 2009
dlhack("followup");
I received quite some feedback on my dlhack() post. Most of it negative.
For clarity: no, I do not consider such practices to be the best of ideas. I called it a 'hack' for a reason—I fully expect this mechanism to be replaced by the time I eventually release the code.
It was just fun to do it this way, that's all.
Having said that,
There's one comment from a xine developer that deserves a followup:
I'm sure I have seen a few different software that can simulate keypresses from the keyboard through the user event interface of the kernel with a joystick, and thus you should just need to wire it down with the original xine-ui. Or use gxine and the gxine_client program to control it.
While this will work, there are several problems with this approach:
- The kernel can't know which application currently has the focus. With this approach, you may be sending joystick-generated keypress events to your IM client because it popped up while you were watching a DVD, and you hit the table (causing the joystick to move) while trying to click it away.
- A keyboard and a joystick are fundamentally different devices. While a keyboard can only tell the difference between 'the button is depressed' or 'the button is not depressed', a joystick has a much wider range; the Linux API will give you a signed 16-bit integer for the position of the stick. This can be useful to skip forward or backward in a much more detailed manner than the traditional 'chapter, 5 seconds, 30 seconds' approach; or one could use it to set the volume to a particular level (activate 'set volume', push the stick somewhere between fully-forward and the idle position for a volume level over 50%, or somewhere between fully-backward and idle for a volume level under 50%, then push a button to confirm). This kind of UI comes naturally with joysticks, but is impossible to implement through a keyboard-emulated UI.
- Some of the functionality I have in mind will require some visual feedback (e.g., the volume setter described above). I could do a separate window, of course, but that has its own set of problems; e.g., you need to ensure that it is on top of the video window; it will also be opaque, which is not as nice as transparent overlays on the xine window itself.
While all of the above is not a problem if I write a xine plugin, and indeed I might eventually convert the code to a one, the problem with that is that I don't know the xine plugin API yet; and writing a standalone application makes for easier prototyping. For the time being, at least.
Oh, and in case you wonder why I don't just buy a LIRC-capable device and use a regular remote control: I have my gamepad. I do not have such a LIRC-capable device. My budget is not unlimited. 'Nuf said.
Some mail is welcome in /dev/null. Real mail, however, is welcome at my email address
|
|
|
|