Current plans for JInput

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Current plans for JInput

gouessej
Administrator
Hi

I suggest the following changes in or near JInput to use it more easily in projects based on JogAmp:
- the automatic extraction and loading of native libraries from JARs as it is already possible for other APIs
- a plugin to use this library with NEWT (like the one for AWT)
- some modifications in Ardor3D to allow the use of such a modified version with JOGL

Best regards.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

Sven Gothel
Administrator
On 05/15/2012 10:46 AM, gouessej [via jogamp] wrote:
> Hi
>
> I suggest the following changes in or near JInput to use it more easily in
> projects based on JogAmp:
> - the automatic extraction and loading of native libraries from JARs as it is
> already possible for other APIs

of course

> - a plugin to use this library with NEWT (like the one for AWT)

You mean the adapter for translating AWT or Android to NEWT events ?
If so, how shall they map to the current NEWT input scheme of
just having Key/Mouse input events ?
Would it imply to generate new NEWT event classes.

> - some modifications in Ardor3D to allow the use of such a modified version
> with JOGL

Sure. This work will be part of your/our Ardor3D migration work, right ?

Cheers, Sven


--
health & wealth
mailto:[hidden email] ; http://jausoft.com
Timezone: Shanghai
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

gouessej
Administrator
As far as I know, the AWT plugin allows to use keyboard and mouse with JInput when the permissions on /dev/input/* do not allow to read its descriptors, it uses AWT events under the hood and it converts them into JInput events. I suggest to do the same with NEWT. I don't know whether it would be possible to add Android support, I have never thought about that.

As for Ardor3D, ardor3d-jogl should include this modified version of JInput and I will provide a "controller" using it, I will have to look at the existing one that relies on the competitor of JOGL. It is not difficult.

If it works before August, I will be able to use it for the demo of TUER.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

gouessej
Administrator
In reply to this post by Sven Gothel
Actually, com.ardor3d.input.jinput.JInputControllerWrapper could be used as is. I will copy/paste it in ardor3d-jogl but in a different package and it will use "our" modified version.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

Sven Gothel
Administrator
In reply to this post by gouessej
On 05/15/2012 03:41 PM, gouessej [via jogamp] wrote:
> As far as I know, the AWT plugin allows to use keyboard and mouse with JInput
> when the permissions on /dev/input/* do not allow to read its descriptors, it
> uses AWT events under the hood and it converts them into JInput events. I
> suggest to do the same with NEWT. I don't know whether it would be possible to
> add Android support, I have never thought about that.

I see, NEWT events -> JInput.
Android would be implicit here if using NEWT.

> If it works before August, I will be able to use it for the demo of TUER.

Sure.

BTW: Whats the official git repo and branch for jinput
     we should use / branch off ?
     Me not familiar w/ jinput.

~Sven


signature.asc (910 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

gouessej
Administrator
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

gouessej
Administrator
In reply to this post by Sven Gothel
The AWT plugin seems not difficult to port to NEWT:
http://java.net/projects/jinput/sources/svn/show/trunk/plugins/awt/src/net/java/games/input

Is it possible to use the automatic extraction and loading of native libraries from JARs without using GlueGen to build JInput?
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

Pixelapp
In reply to this post by Sven Gothel
I don't know about the official JInput. But what I'm going to use is https://github.com/gemserk/jinput https://github.com/gemserk/jutils-jinput which are the same as the original JInput, but maintained by a third party (person).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

gouessej
Administrator
This version is not as up-to-date as the official version as far as I know.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

Pixelapp
Can you say where is the official version? Otherwise this is the one that is going to be used.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

gouessej
Administrator
I already contacted the developer ("endolf") of this library on JavaGaming.org and I already gave the URL of the zipped nightly builds, the URL of the web view on the SVN repository and the URL for its Jenkins continuous integration, just look into one of my previous post. Even on Github, it is clearly mentionned: "jutils dependency of jinput svn sync fork (not official)".

The number doesn't make the reason. Lots of people can do wrong choices, it doesn't mean that they're right. For example, some people put Ardor3D on Github and claimed "we'll keep it up" but it is still not the official version and finally they don't keep it up. I really want to get the latest fixes and features, I don't need to use a "copy" of JInput.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

Sven Gothel
Administrator
In reply to this post by gouessej
On 05/15/2012 06:51 PM, gouessej [via jogamp] wrote:
> The AWT plugin seems not difficult to port to NEWT:
> http://java.net/projects/jinput/sources/svn/show/trunk/plugins/awt/src/net/java/games/input
>
> Is it possible to use the automatic extraction and loading of native libraries
> from JARs without using GlueGen to build JInput?

That would require us to extract at least some of GlueGen's runtime
to a seperate library/JAR w/ a unique namespace.
So .. in general, yes - but it require some work.

We also could simply test whether GlueGen is available (reflection)
and use it, otherwise we follow the traditional lib loading.

I guess the answer lies in our decision whether we maintain our branch
of JInput or not. If we do, we simple make it dependent on GlueGen.
Such decision wouldn't hurt 'us'. While doing so we still could relax it
as described above.

In case we don't maintain our branch, we might need for code inclusion etc,
which might be impossible.

I will follow up on this issue in Julien's answer about differences
and the 'right' source.

~Sven
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

Sven Gothel
Administrator
In reply to this post by gouessej
On 05/20/2012 09:31 AM, gouessej [via jogamp] wrote:
> I already contacted the developer ("endolf") of this library on JavaGaming.org
> and I already gave the URL of the zipped nightly builds, the URL of the web
> view on the SVN repository and the URL for its Jenkins continuous integration,
> just look into one of my previous post. Even on Github, it is clearly
> mentionned: "jutils dependency of jinput svn sync fork (*not official*)".
>
Just to make sure I got it right, you say that the official source:
  <http://java.net/projects/jinput/sources/svn/show>
is being build 'officially' here:
  <http://www.newdawnsoftware.com/jenkins/view/JInput/>

So, 'newdawnsoftware.com' is the 'official' domain for JInput?
They also build LWJGL etc .. are they the official build host of that as well?

 
> The number doesn't make the reason. Lots of people can do wrong choices, it
> doesn't mean that they're right. For example, some people put Ardor3D on
> Github and claimed "we'll keep it up" but it is still not the official version
> and finally they don't keep it up. I really want to get the latest fixes and
> features, I don't need to use a "copy" of JInput.

I am not personally a user of JInput, and I also don't know about
the current state of the project.

The 'JInput on JogAmp' request came up to us with premise that the SVN JInput
source is somewhat no more maintained.
I cannot make a statement in this regard.

If users of JogAmp modules benefit from a JInput module hosted,
build and signed by JogAmp incl. minor patches like native lib loading
I am fine with that. However, somebody shall be in charge of that module
and make sure we use the right source tree and keep it in sync.
As Julien mentions, people always branch and claim their are the new 'fame',
however often they fail to properly maintain their module.
Our maintenance - the person who takes that 'job', should be serious
and communicate well with the original authors.

[1] Repository
IMHO such a branch should start w/ a 1:1 svn -> git repository
  <http://jausoft.com/blog/2009/07/08/svn-to-git-migration-1/>
including the whole history.
The branch should be made publicly available for review.
Later we branch it to our git repository.

[2] Jenkins Build & Test

[3] Patch to optionally utilize GlueGen's native lib loading

[4] NEWT to JInput event adapter

[5] .. more development ..

It's hard to find maintainers to commit to their job,
as we see it for JOAL and JOCL. I guess we can be happy
if somebody likes to fit in these roles and [at least]
qualifies [on the way as we go].

I would love to see users and developers of JInput
like Julien and Vianel/Pixelapp find a common solution/policy
and then we can go ahead - or not.
Then I will help out as I can to make it working.

Looking forward to your conclusions and ideas.

Cheers, Sven
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

Pixelapp
In reply to this post by gouessej
Hey Julien. What we are looking for are the source code. These links you provided are the builds instead (see below).

http://java.net/projects/jinput/sources/svn/show
http://www.newdawnsoftware.com/resources/jinput/
http://www.newdawnsoftware.com/jenkins/view/JInput/

Plus this repository (see below) is out of date.

http://java.net/projects/jinput/sources/svn/show

What do you mean when you say that you have the JInput source code?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

Pixelapp
I'm going to use http://java.net/projects/jinput to develop JInput, unless Julien or someone else finds a better or more official source.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

Pixelapp
Also, as a heads up; I plan to implement Windows Kinect inside JInput.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

Pixelapp
In reply to this post by gouessej
This part http://www.newdawnsoftware.com/resources/jinput/ of JInput has been updated daily, but these changes are not reflected here http://java.net/projects/jinput/sources/svn/show. Do you guys/gals know why?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

gouessej
Administrator
Hi

I gave the URL of the "browser" view of the repository, the SVN URL is:
https://svn.java.net/svn/jinput~svn

However, there is still a need of clarifying some aspects with the original author of this library. As far as I know, it is still maintained, there is nothing wrong. JInput doesn't require a huge investment like JOGL, it doesn't mean that it has been abandoned.

I'm in favor of a minimal fork with a few changes to fully use GlueGen and still keep in sync with the "legacy" version of JInput to get its small evolutions and bug fixes. It should be named and presented as an alternative version with changes for JogAmp, not as JInput. "JInput for JogAmp" is fine for me, it reflects what the project should be, it doesn't replace JInput and it works better with JogAmp.

There are some dependencies with DirectInput (DirectX) and I don't feel comfortable with that.

Finally, I'm going to contact "endolf" anew to obtain some information. Some people claimed that JOGL was dead some years ago, we should not do the same with JInput.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

Sven Gothel
Administrator
On 05/21/2012 05:42 PM, gouessej [via jogamp] wrote:
> Hi
>
> I gave the URL of the "browser" view of the repository, the SVN URL is:
> https://svn.java.net/svn/jinput~svn
>
> However, there is still a need of clarifying some aspects with the original
> author of this library. As far as I know, it is still maintained, there is
> nothing wrong. JInput doesn't require a huge investment like JOGL, it doesn't
> mean that it has been abandoned.
Sounds good.

>
> I'm in favor of a minimal fork with a few changes to fully use GlueGen and
> still keep in sync with the "legacy" version of JInput to get its small
> evolutions and bug fixes. It should be named and presented as an alternative
> version with changes for JogAmp, not as JInput. "JInput for JogAmp" is fine
> for me, it reflects what the project should be, it doesn't replace JInput and
> it works better with JogAmp.
Very reasonable. We can mention it's purpose on a little web page and the README.

>
> There are some dependencies with DirectInput (DirectX) and I don't feel
> comfortable with that.
>
> Finally, I'm going to contact "endolf" anew to obtain some information. Some
> people claimed that JOGL was dead some years ago, we should not do the same
> with JInput.
I agree. Of course we shall not make any claims here, but state the
reason for the patches. In case 'endolf' likes to merge them,
he is more than welcome of course. If 'endolf' likes to move to git as well
even better.

Thank you for handling the communication.

~Sven

> Julien Gouesse
> http://tuer.sourceforge.net
> http://gouessej.wordpress.com
>


signature.asc (910 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Current plans for JInput

gouessej
Administrator
Hi

Endolf confirmed the current source code is here:
https://svn.java.net/svn/jinput~svn

He confirmed that JInput is actively maintained but it just works, bugs are fixed, there are just a very few bugs, then there is no need of a big maintenance. That's what I thought.

He doesn't understand the need of using GlueGen, I tried to explain to him why we need to use it. He would like to be alerted about changes in the public API. He agrees with hosting the NEWT plugin.

I have forgotten to speak about GIT, sorry. Best regards.
Julien Gouesse | Personal blog | Website
12
Loading...