Integrate Newer Nifty (1.4 or 2.0)

What is our plan to integrate a more modern version of Nifty? I’ve run into bugs with 1.3.x that have been fixed in 1.4.

I’m running JME and Nifty from source, so I can tell that we’re going to have to make some (hopefully minor) changes in JME to work with the new version. – For 1.4, it looks like Void’s crew did some package refactoring, so we at least need to modify some of the JME imports. I’m happy to contribute the patches to JME to get 1.4 working, but I don’t want to duplicate effort or patch an old branch. Sadly, I can’t find a dev roadmap anywhere other than discussing infrastructure changes such as moving to GitHub (well done!) and Gradle.

Do we want to integrate Nifty 1.4 or 2.0? I’ve not done the research yet to know if 2.0 is ready for users yet, but I’m happy to investigate.

Which branch of JME should I target?

Apologies if the answer to this question or contribution guidelines are posted elsewhere, I’ve had trouble tracking down anything that looks modern. Alternatively… if you’ve already got a version with 1.4 then I’m even happier to just use it. :slight_smile:

Thanks!

1 Like

With all the Nifty bashing and other GUI libraries emerging @void256 is seen less around here but for the next release we’ll get in contact with him again to see what the best version for jME is at that point, he’s in the core chat. He helped us integrate the jME versions in the past but I’m sure he wouldn’t mind some help :slight_smile: He will have to say if theres a version that doesn’t break current projects and just fixes bugs, I guess Nifty 2.0 should only be integrated in jME 3.1. Maybe he chips in here when he sees my @mention.

Edit: Oh and whats in github master now is whats supposed to become jME 3.1 but its still far from it, any updates for 3.0 would have to be made against the 3.0 branch and not break current jME projects as said.

Oh, dang. From my reading, I thought Nifty was the main GUI lib for JME. In that case can you recommend the up-and-coming GUI lib(s) that are compatible with JME? I’d prefer to just use Swing, but I need to have it lay over the 3D world like a desktop.

Thanks!

@jeffhoye said: Oh, dang. From my reading, I thought Nifty was the main GUI lib for JME. In that case can you recommend the up-and-coming GUI lib(s) that are compatible with JME? I'd prefer to just use Swing, but I need to have it lay over the 3D world like a desktop.

Thanks!

Nifty is still the one bundled with the SDK and I don’t think there are plans to change that in the foreseeable future.

There are two community gui projects depending on your needs: Lemur and TonegodGUI.

Lemur is my project and seeks to be modular and “lightly integrated” in that I use JME where ever possible and extend JME with otherwise useful bits as needed. (For example, I have a wrapper for InputManager that makes managing input easier but is not GUI specific at all.) Lemur GUI elements are just regular JME spatials and can be used in that context (in 3D or 2D) and likewise any JME spatial can be used as a Lemur GUI element just by adding a control to it.
http://hub.jmonkeyengine.org/forum/board/projects/lemur/

The biggest downside to my lib is probably that there aren’t a lot of advanced controls yet. I don’t add anything until it’s been vetted a bit and fully developed so the core set of elements evolves a bit more slowly. It has Button, Label, TextField, etc. along with layouts. I come from a Swing background so I try to make it swing-like where it makes sense… cleaning up some swing nonsense in the process.

TonegodGUI is a larger project with more features. Philosophically different in some ways but ticks a lot more checkboxes:
http://hub.jmonkeyengine.org/forum/board/projects/tonegodgui/

As far as I follow the nifty development, version 2.0 is not really usable yet.
So any effort should go into bundling version 1.4. Also for this particular one, I experienced breaking changes in the Screen interface, and nifty jme3 renderer should be corrected for sure. So I am not sure if this is the right approach currently, if you don’t want to break user’s code. But void256 will know for sure.
Anyhow, I am definitely pro nifty, because I really like the concept that the GUI is split out from backend rendering engine. I agree that nifty is not actually so ‘nifty’ and can be quite clumsy, but hopefully version 2.0 will be swing-alike or something more familiar to users. :slight_smile:

Nifty 2.0 is really just beginning to reveal itself. It won’t be usable for quite some time. However, in the end it will be more usable :stuck_out_tongue_winking_eye: than Nifty 1.x ever was but that will take a while. And I don’t think it won’t be compatible with 1.x at all - eventually there will be a way to read 1.x XML format but everything on the Java side will be quite different. Less clumsy and NOT more swing-alike, sorry. But it will be more nifty :roll:

Nifty 1.4 is not fully backwards compatible with 1.3.x, yes. The Screen interface as mentioned by InShadow has been cleaned up which will break existing code (It’s just a small change, easy to fix though but yes, still a breaking change). Additionally some things have been cleaned up internally which might break existing behaviour. Overall it really should not be really bad but yes, there will be some work necessary to get Nifty 1.3.x stuff to compile and work correctly with 1.4.

The jme3 renderer will need a bit of work too to be adapted to the 1.4 RenderDevice interface. I don’t think it’s much but I can’t probably do that by myself due to lack of time. So any help by people with interest in Nifty and understanding of jme3 internals / renderer would be greatly appreciated :slight_smile:

So overall I don’t know how 1.4 fits into jME release plans and if it would be acceptable that it will break existing Nifty code … at least if Nifty stays bundled with jME the way it is now. If the jme3-nifty.jar would be a separate jar we could have a version for 1.3.x Nifty and a version for 1.4.x Nifty … but I don’t know enough to really judge if that is feasible at all.

2 Likes

@void256, maybe you can host the nifty jme3 renderer on your github like you do for other backends?
Can you also elaborate on your design decisions regarding 2.0 version? Or is there any more appropriate communication channel for this topic? :slight_smile:

In that case can you recommend the up-and-coming GUI lib(s) that are compatible with JME? I’d prefer to just use Swing, but I need to have it lay over the 3D world like a desktop.

There is btw also a Javafx binding, if you are fine with using Java 8 as minimum supported version, and need no mobile device support. You could probably use even swing with that, using the swing panel in jfx. (Though i would take a look at jfx it is somewhat similar enough and way better styleable due to css support)

@InShadow said: @void256, maybe you can host the nifty jme3 renderer on your github like you do for other backends?

Yes, should be possible!

@InShadow said: Can you also elaborate on your design decisions regarding 2.0 version? Or is there any more appropriate communication channel for this topic? :)

Make it suck less is a major design decision for 2.0 8)

I’m concentrating on the Java API side a lot more in 2.0 and I’m very concerned what is going into the public API and what is not. In Nifty 1.x this is really badly messed up with methods that are public but that are not supposed to be ever called by you at all … and stuff like that.

There is more but it’s not written down somewhere. I’ve discussed some things of what is on my mind on freenode irc in #niftygui with others and I think right now this would be the best place to find out more about 2.0.

@jeffhoye said: Oh, dang. From my reading, I thought Nifty was the main GUI lib for JME. In that case can you recommend the up-and-coming GUI lib(s) that are compatible with JME? I'd prefer to just use Swing, but I need to have it lay over the 3D world like a desktop.

Thanks!

Yes it is and will continue to be, I didn’t mean to say we bash nifty or that you should use another GUI library. But as we see jME more as a platform than a simple java library we don’t want to break backwards compatibility within 3.0

Sorry for late response.

I have been waiting 1.4 as it has many improvements and fixes for things like Tabs, Drag’n’Drop, Checkboxes, TreeBoxes etc.
We really need 1.4 release in JME. As there are so many fixes there.

I hope someone will find some time to implement 1.4 into JME.

Thanks.

Any update on this? Why isn’t the SDK downloading updates for nifty already? What’s the hold back?

jME 3.1 already supports Nifty GUI 1.4.1, but jME 3.0 was not updated for this.

1 Like

Nifty isn’t backwards compatible so we won’t break 3.0 apps with an update.

Edit: Oh and Nifty is an external library, nothing is stopping your from doing an adapter for 3.0. Go ahead, have fun and keep us updated on what the hold back is.

Wait, what? The site is not clear, then, because I thought I had the latest SDK, and I did click on “Check for updates”, and found none. Also, http://jmonkeyengine.org/ greets in big letters “jMonkeyEngine 3.0”. So, whenever JME 3.1 came out, someone is being lazy about it.

I’m not a game dev, I mostly play with JME as a hobby, so I’m merely taking what I see, officially.

jME 3.1 did not come out, but it is the next version to be released and supported, which is why all the libraries, like Nifty GUI, are updated for it.
Essentially, 3.0 will not be getting any updates except for critical bug fixes.

Did you wake up on the wrong side of the bed today?

That’s it you guys! You are all fired and I’m docking your pay for the whole month. :wink:

1 Like

Wait…you guys are paid?

You are too… you’ve gotten a 50% raise every year since you started. Of course, we all started at 0 so…