Simple jinput proposal, feedback wanted from users and Jeff :)

Hi

I’ve noticed that the most common issue is the plugins system. I’m proposing that in the default controller environment, unless a property (jinput.loadDefaultPlugin for example) is set to false, it will load the defaut plugin, for that environment, based on what we have in CVS. That way, we can then also modify the main build script so there are optional build targets that product a single jar and native lib for each of the 3 main platform. We gain ease of use, but still maintaint the option of the plugin system.

Discuss.

Endolf

Yes, please.

Kev

Sounds like the well working JOGL way, so: yes, please.

P.S. I’m not yet using JInput (which is the reason why I’m usually silent on the topic) but as a happy JOGL user I’d love to see a similar up to date multi-platform release thing for JInput.

Sounds very good to me :smiley:

// Gregof

Hi

Build scripts updated and new binaries are available from the files section on jinput.dev.java.net for windows and linux.

These new builds contain 1 jar and 1 native library. Left alone, it will just work ™, loading the right plugin for the platform.

If you want to use the plugin mechanism, it’s still there, unchanged, so just have the controller dir as before, or set the class names in the properties.

If you do not want the default plugin loaded, there is a new property to disable it’s loading. Set jinput.useDefualtPlugin or net.java.games.input.useDefaultPlugin to ‘false’.

Endolf

Edit: typo

Yes please

// Tomas :slight_smile:

Nice simpel solution.

Thanks End.

SOemthign Iw as considering awhiel back, btw, but never ahd tiem to implement was adding a “isSupported” call on the JInput plugin interface that would return if it was wupported on the current platform.

This would theoretically allow a single build to work on all paltforms (although yould have to destruibute all 3 native libs with that build) as the code coudl decide which to use or not use at run-time.

Just a thought.