Listeners in the new HIAL version (1.5)

Engines, Libraries and Tools Xith3D Forums
#1

hi

When I last emailed with Will, he pointed out that the new listener interfaces in the new HIAL version that I introduced besides the old ones to keep backwards compatiblity could easily replace the old ones. In other words: the old listeners can be removed. I agree with him. Naturally there’ll be a problem with the backwards compatiblity after the removal.

So please make some statements to the following questions:

  • Are you currently using HIAL?
  • Would it be hard for you to loose the old listeners and use the only the new ones?
  • If it is too hard for you to switch to the new listeners, would it be a problem for you to stick to the old version of HIAL?

I would be very happy about some replies.

Marvin

PS: Version 1.5 introduces the possibility to make use of the mouse wheel, adds the x and y coordinates as parameters to the pressed and released events of the mouse listener interfaces and adds an “onMouseStopped” event which is fired when the mouse is not moved for a certain (customizable) amount of time (useful for tooltips). If anyone told me a good way to solve the Linux-AWT-pressed-released problem, it will also be solved an this version (1.5.1?).

#2

Yes

No, not at all.

Now is it really needed to break compatibility ? Can’t we just add new kinds of listeners ?

#3

hi, Amos. First of all, thanks for your reply.

[quote="<MagicSpark.org [ BlueSky ]>,post:2,topic:28211"]
Now is it really needed to break compatibility ? Can’t we just add new kinds of listeners ?
[/quote]
This is the way it is now (new listeners besides old listeners). William stated, that he had no problems with removing the old listeners and I agree with him, if nobody has too much trouble with it. That’s why i stated this thread. I want to get a view of the current situation concerning HIAL. So you told not having too much trouble with the port from 1.4 to 1.5 when we leave the old listeners, I won’t, too. If there was nobody who had serious problems, when we break the compatiblity, there’s no good reason to lug two versions of each listener.

#4

This is the way it is now (new listeners besides old listeners). William stated, that he had no problems with removing the old listeners and I agree with him, if nobody has too much trouble with it. That’s why i stated this thread. I want to get a view of the current situation concerning HIAL. So you told not having too much trouble with the port from 1.4 to 1.5 when we leave the old listeners, I won’t, too. If there was nobody who had serious problems, when we break the compatiblity, there’s no good reason to lug two versions of each listener.
[/quote]
But but but but remember we really should release Xith3D 1.0 and then fork or somewhat else.

I’d really like to have a library which I’m an owner and I can change whatever for design reasons. An SVN project where we would be working together (for our game projects) would be just fine to me. No wide phantom user base, no compatibility issues (we just have to state that you can’t complain if you use that) and no crappy half-buggy forgotten code somwhere in the hidden repository.

What’d you think ?

#5

[quote="<MagicSpark.org [ BlueSky ]>,post:4,topic:28211"]
But but but but remember we really should release Xith3D 1.0 and then fork or somewhat else.

I’d really like to have a library which I’m an owner and I can change whatever for design reasons. An SVN project where we would be working together (for our game projects) would be just fine to me. No wide phantom user base, no compatibility issues (we just have to state that you can’t complain if you use that) and no crappy half-buggy forgotten code somwhere in the hidden repository.

What’d you think ?
[/quote]
Ok. I agree.

So let’s work on a roadmap for 1.0 during the next month or so. And than I would be really happy to discuss such a project with you.

#6

I use HIAL and have no problems with changing the listener stetup

The 1.0 release sounds good,

Are you considering reworking the Xith project or starting something new friom scratch??

#7

In this particular case, backwards compatiability is preserved by simply deprecating the entire previous listener API and providing a new one. Personally, I feel if this is the case - anyone really wanting to keep using the old API can by simply not upgrading. This is different to say backward compatability where new features are added while preserving existing ones (deprecating only a method or two).

I’d suggest re-releasing 1.5 (maybe as 1.51) where there is a single version (with no ‘2’ suffix). Either keeping backwards compatability by not renaming the methods, or not by adopting the new names instead (I believe Marvin prefers the latter which is fine by me). I don’t think the implications of either actually matter that much since most people are probably using the implementations such as KeyArrayListener (isPressed() method) and not the raw listener interfaces anyway.

Marvin, sorry for not getting on to this sooner - I’ve been very busy and only just got a chance to have a look. Thank you for maintaining the API. I’ll contact you about getting the new version up on http://input.jtank.net/

Amos, regarding your comment - I would suggest not forking Xith3D. You can gain valuable experiance (and exposure) by maintaining a public API and helping its userbase. Sure it’s easier when you’re not answerable to other users of your API, but unless you plan never to work in a larger group it’s worthwhile to get experiance with this. Also, a public API can have new people contributing new ideas and work which you can benifit from if you’re still using it.

Cheers,
Will

#8

@hawkwind, WillDenniss, and Qudus, please read that :
http://www.java-gaming.org/forums/index.php?topic=14768.0

#9

I’ve just removed the old Listeners and removed the “2” postfixes from the new ones.

For the release: I’ll do that at the end of the next week. I’m planning to implement a JInput abstraction to HIAL to support Joysticks. Will all be done next week.

Marvin

EDIT: btw. What is the advantage of ant? Why don’t we release things as a jar compiled by eclipse and regular javac? It seems like ant does nothing better but everything more complicated, doesn’t it?

#10

Well the thing about ant is that it automates the whole and is IDE-neutral.

Please makes me check your jars before releasing (or make Will check). It’s good to be 3 to be able to do releases.

#11

[quote="<MagicSpark.org [ BlueSky ]>,post:10,topic:28211"]
Well the thing about ant is that it automates the whole and is IDE-neutral.
[/quote]
No other “advantage”? IDE neutral has no value for the resulting jar (am I wrong?). And the jardesc in eclipse automates the thing in a much better way as I think, doens’t it?

[quote="<MagicSpark.org [ BlueSky ]>,post:10,topic:28211"]
Please makes me check your jars before releasing (or make Will check). It’s good to be 3 to be able to do releases.
[/quote]
I sent you an email.

EDIT: I didn’t send you my test case for HIAL for two reasons. 1. It is not included in the resulting jar. 2. Do not make you possibly do the same mistakes I may have done you should make you own test case. (And it is not too much work.)

#12

No other “advantage”? IDE neutral has no value for the resulting jar (am I wrong?). And the jardesc in eclipse automates the thing in a much better way as I think, doens’t it?
[/quote]
Build from Eclipse seems fine to me.

#13

Well I am a big fan of Ant, even though I used to use Eclipse to compile anyway. It just means that anyone can build the project simply by typing “ant”, regardless of IDE. Some people do use other IDE’s like NetBeans too. Maintaining ant has never been an issue for me (what needs to be changed? only changing dependancies and version numbers normally).

We’re not using C++ here where everyone is using Visual Studio - keeping things IDE neutral is good practice in the java world. IMHO.

Will.

#14

Ant can also be used to automate the otherwise painful release process. Being able to create a release (with all the various components) by a single command means there is no reason not to release new versions often.

Will.

#15

The other advantage to ANy is it persists knowledge even if the author is no longer involved with a project. Press A and the tool builds…period, no other knowledge is required. Just a thought.

William how goes it. You have been silent recently…work keeping you busy??

#16

Very good thanks hawkwind - yourself? Work is keeping my very busy and will for some time to come. That said, I’m not complaining at all as it is game development :slight_smile: Can’t wait to share what I have been working on, but that won’t happen till next year when it’s finished.

It’s great to see that Xith3D’s being maintained and new projects like JOODE getting some attention.

Cheers,
Will

#17

Everybody C++ uses Visual Studio ? Ahmm, Will, never heard about Linux ? ;D ;D ;D ;D