Hi
I’ve not received or read about any bugs with the linux plugin for jinput, so would I be correct that no-one has tried it?, if you have and it works i’d also like to know :), bug reports are welcome.
Cheers
Endolf
JInput (like JOAL) are two APIs that haven’t been truly exploited yet. Give 'em some time 
Its on my list… but its a long list… 
Are there any unit test in the CVS codebase yet? If you have some test code I will try to give it a whirl on my Linux box. I think tests for jUnit are on the ToDo list anyway.
Hi
OK, that confirms what I thought :), how do you plan on doing unit testing on the native library without sitting there with a joystick and twiddling witht he buttons and axis and thumping the keyboard every now and then?
Cheers
Endolf
Good point… perhaps there will be a bit of UI to the tests.
E.g. first a simple press a key… if it isn’t pressed within 10 seconds the test fails.
Then for each controller… press and release all buttons (one at a time). The test can pass once all buttons have been observed in both the pressed and unpressed states. Fail with a timeout, or maybe ‘Esc’ detected via AWT.
Then try each analog axis, confirm more than just 2 values read back from them.
Not perfect, actually not much better than ControllerReadTest… hmmm. and actually since my Powerbook reports 2 mouse buttons but has only one mouse button it would always fail argh…
I’ll try to get the ControllerReadTest going on my Linux box tonight. I will only be able to test mouse and keyboard.
There is unfortunately no reasonable way to do JUnit tests with external devices since someone has to actually be sitting there pressing the keys and confirming that what was pressed is what the correct result is on the screen. Same for joysticks, rumble and the like. Since all of the stimulus requires an external entity, automated testing won’t work.
Well ‘automated’ testing won’t work, but that doesn’t mean that we shouldn’t have a test suite to make it is easy to cover all the manual testing that should be done.
The only automated testing would be something that runs on a system with known devices and checks that at least all the controls are reported properly in in the idle state. E.g. make sure the mouse has a mouse ball, the keyboard has keys, and that no buttons are stuck on. Not that impressive I guess…
Yeah, that’s not particularly useful
Well, my nascent idea for Junit tests is to have a “testing plug-in” that fakes the outside world with well known results.
Granted this won’t test plug-in changes but it will at least test that the core is still in decent shape.