Any suggestions? 
Endolf
Hows about component?
of course the problem here is that a sub controller is also a component, so itās still ambiguous :), and I still think sub controllers are required, so they aint comming out :). We could introduce a method getAllComponents(Component.Identifier) that returns all the axis, on this device and itās subdevices, that returns much like the getComponent(Component.Identifier) method, but searches itās sub controllers too if that would be an appropriate compromise?
Component.Identifier.Button.X
Component.Identifier.Axis.Z
Hmm
Endolf
I donāt see any need to rename Axis and would definitely vote against it.
As for the double āAxisā in the use of identifiersā¦ maybe try āAxis.Identifier.Generic.Xā instead of āAxis.Identifier.Axis.Xā
my reason for renaming:
my name suggestion:
A Controller with Controls which can be either Buttons or Valuesā¦ makes sense if you want to follow HID conventions.
Though I find the HID terminology a bit wacky in some places - e.g. āvalueā
But I fail to see how this solves any problem. Documentation will be no more clear with Controller and Control, control, etc. Isnāt the whole point to name it Axis exactly because that is the device feature???
Hi
Right, for now the name stays as Axis, I was willing to go either way with it, based on what the community wanted, and we got one vote to change it and one to leave it, so for now, out of laziness, it stays :). Iāll do all the other Axis.Identifier changes. I have no way to test or even build the mac changes, although it should be just java changes, so can an osx user build and test it. I imagine it will be later on in the week before I get to start this as Iām in the process of moving flats.
Endolf
agreed, although not happy - maybe we can address this again at a later time when there is a bigger user base for jinput.
@endolf:
could you please change the filenames of
[]the native libraries
[]the resulting jar files
because:
The current names (dxinput.dll, libjinput.so, linux.jar, HIDWrapper.jar, etc) are not consistent nor are they self-explanatory or expressive. I suggest something that makes it clear ā¦
[]that it is a plugin for JInput (or its native library)
[]which OS/hw hardware architecture it can run on
[*]what OS feature it uses or what input device it supports
Ok
The coreAPI changes have been made (not in CVS yet), and Iāve updated DX8 and linux plugin. (again, not in CVS yet). Iām going to need some testers before I commit it, itās a significat (but not large) change, and it will break everything if itās not right :). Iāve done my own testing on windows, but Iām in the process of moving house, so I donāt have access to my linux dev box.
You can get the changes to test here, you will need the coreAPI and one of the plugins. Please let me know if it builds, if it runs, any errors, or if it all fails horribly, all reports are welcomed.
Cheers
Endolf
Ok, I am going to test this.
for the linux plugin I can say that it works although there are 4 abs axes which do not do anything - thats why in my plugin i just ignored them. please have a look at the minimum and maximum data the kernel provides. the problem with these axes is that they marked as being pressed constantly (-1) which is very bad for input autodetection.
another bad thing is that my pc speaker is still a non-usable but visible input device.
another small problem: Controller.getAxes() still exists but returns the Component array. apidoc is outdated too.
[quote]for the linux plugin I can say that it works although there are 4 abs axes which do not do anything - thats why in my plugin i just ignored them. please have a look at the minimum and maximum data the kernel provides. the problem with these axes is that they marked as being pressed constantly (-1) which is very bad for input autodetection.
[/quote]
Is this a new problem, or did it do this with what was in CVS? Can you send me the dump from a texttest and readtest?
[quote]another bad thing is that my pc speaker is still a non-usable but visible input device.
[/quote]
Ok, I now throw away anything that has no sub controllers and/or no components.
[quote]another small problem: Controller.getAxes() still exists but returns the Component array. apidoc is outdated too.
[/quote]
renamed method and updated the docs (I think I got them all)
Endolf
[quote]Hi
Right, for now the name stays as Axis, ā¦
[/quote]
Apparently not?
Thumbs down to the rename.
public class Axis {
public class Identifier {
public class Key extends Identifier {
}
}
}
Will result in compile errors 
Endolf
Are you sure you want all those inner classes? Seems a bit twisted. Maybe you want to stick āstaticā in there somewhere?
e.g.
class Axis {
static class Identifier {
}
class Key extends Identifier {
}
}
I did ponder pulling Identifier out into itās own class, but the identifier is unique to a component/axis/whatever we call it. I also pondered creating a package for the controls and pulling out keys from the keyboard, and axis class, a component interface and a button class, then moving the Identifier object in there, or even having identifier as a package inside the component package and placing Identifier, KeyIdentifier, ButtonIdentifier and AxisIdentifier in there. If thats what people would prefer, then we could go that way too.
Endolf
I donāt understand why you would do all that. But maybe Iām simply not getting it.
It seems to me that Axis.Identifier fits well.
That is Identifier as a nested class of Axis, not an inner class.
That is the CLASS not the OBJECT. Each Axis can have a member object of type Axis.Identifier.
Someone needs to invent a āprogrammers forumā where it is easy to create UML diagrams in the message threads
Hi
Ok, Identifier as a nested class rather than an inner class, thats not a matter for debate really, it makes sense, iāve done the change (not that itās hard), iāll commit it later when Iām not on works vpn and can actually use things other than port 80. Grr atta nasty vpn software that wonāt let me access anything except the vpnād network, not even me own lan.
Endolf