Core API changes for Axis.Identifier are looking like they will be going in to CVS soon, that means the work breaks if you are on OSX (any OSX devs out there?? :)). Linux and DX plugins should be done, so you will need to get all of them. I’ll post back when i’m about to commit, and again when I do commit.
See this thread.
Endolf
Summary of changes
Axis is renamed Component.
Component.Identifier should not be extended unless you have specific devices you are writting for, and then it would be better to update the core one. There are identifiers listed for buttons, axis and keys, please use them rather than your own :). It means that all the plugins will be consistant. There are lots more buttons especially defined now.
Endolf
I’m against the change. Axis is a proper term for buttons (including keyboard keys), and analog controls. Component is already overused in the JRE. This rename isn’t useful and in fact makes things worse.
[quote]Axis is a proper term for buttons (including keyboard keys), and analog controls.
[/quote]
How so?, a keyboard has no axis, it has keys. A mouse has 2,3 or 4 (I’ve not seen any more) axis, it also has a number of buttons. I don’t think calling a button an axis is correct.
[quote] Component is already overused in the JRE. This rename isn’t useful and in fact makes things worse.
[/quote]
It’s a component of the controller. It seemed better than ‘bit’, ‘thing’, ‘whatsit’ or ‘ingredient’. The HID standards were mentioned to name it Control, but a controller with controlls would have been confusing, as you pointed out. I’d be happy to rename it if something better was suggested. I’m not sure how it makes things worse. Purley because there is already a Component class defined in AWT?. I’m trying to see the issue here, but I can’t seem to get what you are saying.
Endolf
Good thing - as already said: I found documenting complicated with ‘axis’, ‘axes’ and ‘Axis’.
Call a button a button.
Cas 
Perhaps it is the ‘controller’ which is misnamed.
Controller ==> InputDevice
Axis ==> Control
Ah thanks. Someone else then me mentioned renaming both. (done that in a different thread)
Now again with Mark’s support:
Please rename both classes.
I don’t see that is being equivalent nor better.
For one a Control may have more than one Axis (e.g. X and Y on a stick), you do not treat them as separate controls, but they are separate Axis.
Perhaps Controller is over used in that it is used to group controls on a single device, so there are Controllers and sub-Controllers?
Maybe we need
InputDevice
which has Controls
which have Axis
?
But the more I think about it the more it seems that the original way is correct. Buttons ARE Axis, knobs are Axis, sliders are Axis, all of these are on a Controller. Though sometimes Axis are grouped (stick with X & Y, flight yoke with X,Y & Z), a general grouping of sub-controllers to accommodate this seems reasonable.
[quote]Controller ==> InputDevice
Axis ==> Control
[/quote]
Works for me.
Endolf.
But it’s simply wrong!
Axis != Control
e.g. a stick is one control with two Axis
Why is there any desire to change what we have???
With the extreme simplicity of LWJGL’s approach to input devices I wonder what cas has to say about JInput’s concept of subcontrollers …
Calling everything an ‘Axis’ that is in fact a button, slider, axis etc is quite unusual. AFAIK JInput is not the only library that manages input devices so let’s have a look what others do:
a) SDL (see libsdl.org - Doc Wiki)
b) ClanLib (see clanlib.org - docs)
c) Allegro (see allegro.cc - Online Manual)
I just do not get why JInput has to do it more complicated than any of these libraries.
JInput doesn’t call an button/key an axis, the Axis class has already been renamed Component. We have Controllers and Components. Whilst I agree that an axis is a control, and so is a key, Controller that has Controls would be confusing. The trouble with calling it InputDevice is that a force feedback gamepad for example is not just Input. What is the proper collective term for all Axis, buttons and keys?, it’s certainly not Axis, hence it was renamed. Part of the reason JInput is more complicated is that it was not designed purely for joysticks. It was designed for input. Thats my understanding anyway. Otherwise there would be 3 classes, joystick, mouse and keyboard. JInput already supports digitisers for example.
Endolf
[quote]JInput doesn’t call an button/key an axis, the Axis class has already been renamed Component.
[/quote]
Which was a significant mistake in my opinion.
[quote] We have Controllers and Components. Whilst I agree that an axis is a control, and so is a key,
[/quote]
I think a key is an axis on a keyboard control.
[quote]Controller that has Controls would be confusing. The trouble with calling it InputDevice is that a force feedback gamepad for example is not just Input.
[/quote]
Right. controller works fine and is accurate.
[quote]What is the proper collective term for all Axis, buttons and keys?, it’s certainly not Axis,
[/quote]
Yes it is!!!
Seriously get a dictionary. The term axis fits. Think in mathematical terms… x,y axis for sticks, a single axis for one-dimensional controls like buttons and keys, or knobs, etc.
Think of inputs on a controller in terms of coordinate systems and the state of the device. Each button or stick adds axis to the coordinate system.
I noticed that some how
[quote]Seriously get a dictionary.
[/quote]
Ouch, but ok, hmm, I can see how a joysticks X, Y, or throttle axis are there, but, erm, a key doesn’t rotate. I suppose a key/button goes up and down on an axis, and that line could be thought of as one, but it seems like stretching the definition to me.
On the other hand, if the bigest concern is what we call the things on a controller, then JInput can’t be all that bad 
Endolf
[quote]The trouble with calling it InputDevice is that a force feedback gamepad for example is not just Input.
[/quote]
But then the whole API should not be named JInput … no just kidding.
IMHO its more common knowledge that there are force feedback enabled input devices than naming a keyboard key an axis …
Lets have a look at the Java API: Gues how the Java Sound API (javax.sound.sampled) named the ‘thingies’ that make the volume, pan etc? A ‘Control’, right.
Btw: I wish JInput would look more often at the JDK to adopt well-known patterns from it, eg. service provider interface instead of ‘yapm’ (Yet Another Plugin Mechanism)
Sorry for being a bit harsh. I needed a vacation, now I’m back
Neither does the joystick. The axes are simply used to form a coordinate system to measure the state of the device. For buttons there is one Axis.
Imagine a button that is sensitive to pressure - such as an USB music keyboard. Now the state of that button not just 0 or 1, as measured on the button’s axis, but some other number within a range.
[quote]I suppose a key/button goes up and down on an axis, and that line could be thought of as one, but it seems like stretching the definition to me.
[/quote]
I think of it as generalizing… which is exactly the sort of thing that the base class Axis is - a general representation of an input. I realize that it is not what you would typically think of, but I think the generalization applies well to all input types.
[quote]On the other hand, if the bigest concern is what we call the things on a controller, then JInput can’t be all that bad
[/quote]
Yeah, point taken, I just thought it odd that it was something that you thought needed changing, and the alternatives proposed seemed to all make more assumptions about the role of Axis.
I can see that an Axis is “not bad” in it’s mathematical defintion; however, I see the following problems:
the common definition explicitly mentions it as a rotational reference-line (c.f. http://dictionary.reference.com/search?q=axis - not a “perfect” dictionary, but a good HCF of people’s common definitions). Hence a lot of people are likely to expect axes to be rotational :(.
“axis” and “axes” are difficult words for english people 
the pronunciation is similar enough to be damn confusing in speech (easy to mistake one for the other) and it’s sufficiently rarely used outside of co-ordinate-space axes that a lot of people probably double-take when they read it and have to think about what it means
Personally, although I’ve got a sneaking suspicion there’s a similar word that more accurately describes the meaning, I’d rather like an “InputDevice” to contain one or more "Input"s (aka “Axis’s”). That also makes it clear that they input data rather than output it (c.f. force-feedback devices).
…and I can write “input’s” (referring to the programmatic plural of input without impying a different class name) and have it look less stupid than “axis’s” (which is IMHO the correct plural of a class named “axis” but looks and sounds horrid).
A “Controller” with Input’s sounds equally good to me too :).
As to whether “InputDevice” is good or bad for force-feedbacks, I see a force-feedback device conceptually as “implements InputDevice, OutputDevice” - just because it happens to output stuff doesn’t affect the fact that it is a fully valid InputDevice as well.
InputDevice compared to Controller? Well…three things:
Both are pretty obvious (unlike the other areas of contention, I think either would be acceptable - but it depends on your personal profesisonal / programming background; c.f. next points)
I slightly prefer InputDevice (as many others would) because I see it so often in my OS (linux: you have XFree86 configuration uses “InputDevice” and you see it a lot in linux-USB docs, config, drivers, etc - probably influenced by the X11 name) and because when I browse the javadocs for an API called “JInput” without a decent package.html telling me where to start, the “InputDevice” is going to jump out at me as a starting point because of the prefix-similarity with the API name. This is a small thing, but otherwise I’d have been equally happy with Controller, and this just gives it a small edge!
I think “Input-device” is often also used in USB manufacturers manuals - ISTR Wacom refers to their own hardware this way.
2 & 3 explain why I think everyone will fall into one of those camps.