I'd like to ask the community about a simple change in the API.
Elias, Cas and me (I haven't talked to spasi, erikd about this since I don't have them om my instant messenger *hint* *hint* guys :) ) have talked about making public read only fields only accessible by get* methods. This would for instance change Mouse.dx to become Mouse.getDeltaX (or getDX).
The specific reason is that it allows us a bit of flexibility (and not to forget, it's a good coding practice) - at the cost of easy access.
Whats YOUR opinion?
*shrug* Sounds good to me! Should make things easier for new users, more Java-like etc. The names getDeltaX() and getDX() are pretty ugly though - don't know what you can do about that!
Completely agree. Read-only access must be provided via a getter, in case when using of the final modifier is impossible. This makes the API more clean and transparent, so you don't have to guess (or refer to documentation) about a property being read-only or not. 8)
Sure, no problem. Oh, and I like the delta name :P
Sounds good to me. Most people who use Java shouldn't mind. Plus, of course, if you make the method final, it should be inlined anyway. (or at least have compile time binding).
It has been done...
I've also added Mouse.getX & getY - so that we have an absolute mouse position. x, y will be updated on Mouse.poll, and if the window has been created it will be clamped to that (0 -> width/height)
Is it possible to improve the javadoc on Mouse.poll(), Mouse.read(), Keyboard.poll() and Keyboard.read()?
"Polls the mouse" and "Reads the mouse buffer" is not very helpful when you look at the javadoc for the first time. In particularly since there are two different methods to getting the input.
Mouse.poll() should mention that you can get the delta from the last poll by using getDeltaX() and getDeltaY(), and that you can get the absolute mouse position using getX(), getY().
Mouse.read() can say that that the events can be read by the next() function.
The same applies to Keyboard.
This will help distinguish the two different methods of getting input, and will be alot less confusing.
thanks, and done :)
This is really an area where users/developers can shine! - the docs really need to be *much* better - however this steals what little time we have to improve the LWJGL :/
Great!
I think most of the docs are good. Changing from static fields to getters also helps. Although there is always room for improvement :wink:
The only other function that really need to change is Keyboard.enableTranslation(). Did not have a clue what this did until I looked at the source. The doc must be clear that this enables getEventCharacter(). The getEventCharacter() doc should also mention that enableTranslation() must be called first.