Just a simple question on this GUI Library in its development stages. So how do you like using it compared to Nifty?
I’ve been away for awhile. Not because of choice, but more of work and life issues. But would like to eventualy try this new GUI interface once I can set some time aside.
And from reading through these forums from time to time, I’m guessing someone like @madjack could offer up some good pros and cons.
Just curious.
The library is quite good actually.
Chris is very often around to answer questions, fix bugs, be an all-around patient and nice person while we pester her with requests and bug reports. Definitively something we can’t say about the other lib.
Unified constructors is a great idea. All controls share the same constructor and that makes it a breeze. You don’t have to constantly refer to docs.
It’s jME native. No “special” lib or dependency. All you need is inside jME.
Generally easy to use and learn.
As far as cons… There aren’t that many really. But there are side-effects to it being in a late-alpha stage. Code changing and evolving, missing functionality (but as of now nothing critical and new important stuff is added quite fast if you let Chris know) but nothing really big. The main issue is it’s not complete.
Besides this, transition is always a pain so you might have a bit of problems going from one system to the other. It takes time and it might be better to start from scratch instead of adapting the Nifty stuff and converting this to the new Lib.
Finally, even if it’s fairly solid and easy to learn, you still have to learn the ropes. Takes time. But compared to Nifty, it’s a much faster process.
I’ll second what @madjack said… I know I wrote the library, so I have a bit of a biased opinion, but… I also use it, so I have my share of likes/dislikes as well =)
What I like:
What I don’t like:
EDIT: I have one more big one to add to the dislike list. I have provided no support for touch input yet. This will be added, and the UI should work quite well for android apps, especially with the use of texture atlasing… however, currently there is no default event handling for this. Pssst… this is the chance for some android guru to step up and say… I can help you little lady!
I changed from Nifty to tonegodGUI a few weeks ago and I must say even in this alpha state I definitly prefer it over Nifty. Its just so much simpler
and easier to use especially when you’re doing “just” a quick prototype gui to have something working.
The only thing that I do not like about it, is the UID stuff in every constructor. I know that this will be important when there will be the possibility
to define the GUI in XML but the way I use it (completely code driven using a scripting language) it has absolutely no use for me (at least I dont
see any advantage for me).
I think it would be a good idea to have a seperate constructor without the UID parameter. I think a unique id can be easily created using a index
or guid in the screen. Maybe with some control specific prefix… However, this is just a really small issue.
From my point of view I would recommend using tonegodGUI and be happy with it;)
Ah - and btw. I think this is one of the most active contribution
I was surprised by the amount of dedication by t0neg0d for this. And was considering checking it out, as I saw some impressive results from it. The only thing concerning me was the android part, and I was gonna ask about it, but that was for the rendering side, as I know u love shaders 
and post processors. Have you tested it on android, there’s a lot of conversion of jME events, so I think it may be ok.
@TsrKanal said: I changed from Nifty to tonegodGUI a few weeks ago and I must say even in this alpha state I definitly prefer it over Nifty. Its just so much simpler and easier to use especially when you're doing "just" a quick prototype gui to have something working.The only thing that I do not like about it, is the UID stuff in every constructor. I know that this will be important when there will be the possibility
to define the GUI in XML but the way I use it (completely code driven using a scripting language) it has absolutely no use for me (at least I dont
see any advantage for me).I think it would be a good idea to have a seperate constructor without the UID parameter. I think a unique id can be easily created using a index
or guid in the screen. Maybe with some control specific prefix… However, this is just a really small issue.From my point of view I would recommend using tonegodGUI and be happy with it;)
Ah - and btw. I think this is one of the most active contribution
[java]
public class UIDUtil {
public static String getUID() {
UUID uuid = UUID.randomUUID();
return uuid.toString();
}
}
[/java]
FTW! I don’t use the UID system either. =)
@wezrule said: I was surprised by the amount of dedication by t0neg0d for this. And was considering checking it out, as I saw some impressive results from it. The only thing concerning me was the android part, and I was gonna ask about it, but that was for the rendering side, as I know u love shaders :p and post processors. Have you tested it on android, there's a lot of conversion of jME events, so I think it may be ok.
I’m going to start looking at it this coming week. Adding extra support for gestures should be as easy as event forwarding from the screen class… but it is great to hear that common events are handled by JME automatically!
My guess is… all should work okay, with the exception of potentially having issues with some of the effects and the caret/text range display of textfields (I’m hoping this is just my paranoia). Enabling global texture atlas usage will be ideal in this case.
One of the changes I see in the future will be decoupling the default style. There really isn’t a need to have the extra xml/images tag along with your app if you are not using them. This will likely happen when it reaches a solid alpha and I have a chance to put together theme plugins. Also, at this point I’ll have updated the wiki with a more in-depth walk-through of creating a custom theme.
I used nifty and liked it. Using tonegodGUI currently and loving it.
I use uids, because I enriched the tonegod adapters and the events triggered so my listeners can use the uids to decide what to do.
Basically, I can specify a listener in the constructor of my enriched adapters and the listeners receive the uid of the source of the events. That way, I can centralize the dispatching of processing of events for my different windows and the code is less verbose. Each window is made of a displayWindow, a controller and a listener. Uids are pretty central to the way my display work.
NB: probably not the best way, but pretty much suit my needs.
@t0neg0d said: ...FTW! I don't use the UID system either. =)
Why not put this into another constructor of the base Element class without an uid?
@loopies said: I used nifty and liked it. Using tonegodGUI currently and loving it.I use uids, because I enriched the tonegod adapters and the events triggered so my listeners can use the uids to decide what to do.
Basically, I can specify a listener in the constructor of my enriched adapters and the listeners receive the uid of the source of the events. That way, I can centralize the processing of events for my different windows and the code is less verbose. Each window is made of a displayWindow, a controller and a listener. Uids are pretty central to the way my display work.
NB: probably not the best way, but pretty much suit my needs.
This sounds cool. I’d love to play around with it if/when you have a chance to share.
@TsrKanal said: Why not put this into another constructor of the base Element class without an uid?
I thought about doing this, however it would require 3 more constructors and I figured since you have to pass in the screen anyways, cutting and & pasting UIDUtil.getUID() wasn’t that big of a deal. Still on the table though… weighing the pros/cons.
I will, however add the utility class to the core.util package.
@t0neg0d said: I'm going to start looking at it this coming week. Adding extra support for gestures *should* be as easy as event forwarding from the screen class... but it is great to hear that common events are handled by JME automatically!My guess is… all should work okay, with the exception of potentially having issues with some of the effects and the caret/text range display of textfields (I’m hoping this is just my paranoia). Enabling global texture atlas usage will be ideal in this case.
One of the changes I see in the future will be decoupling the default style. There really isn’t a need to have the extra xml/images tag along with your app if you are not using them. This will likely happen when it reaches a solid alpha and I have a chance to put together theme plugins. Also, at this point I’ll have updated the wiki with a more in-depth walk-through of creating a custom theme.
ok cool, good luck 
Sure, I’ll start a new thread so I don’t pollute this one with my code.
Posted examples here: http://hub.jmonkeyengine.org/forum/topic/enriched-adapters-and-events-uid-specify-listener/
I’m just a curious observer but I still understand why UIDs are required at all. I can see how a UID could be used to match stuff up from XML (where you can’t have the actual object references) but then it seems like it could be an optional attribute for that use case.
I’m currently in the process of converting from Nifty to TonegodGUI, and I find myself throwing away tons of framework code that TonegodGUI simply doesn’t need.
I found Nifty to be extremely fragile wrt. initialization order. It’s really built for loading everything from XML, and never really changing document structure afterwards. My approach is to build stuff from code, and initialize properties/subcontrols wherever the necessary data becomes available, so I’m constantly fighting Nifty’s standard way of working - it’s been really unpleasant.
Also, Nifty has a really whacky way of dealing with properties - everything is put into a PropertyName->PropertyValue Map, all Strings, so data is continually converted. It’s really backwards to do that; I suspect Nifty started life as an XML-to-GUI converter so everything was strings anyway so it didn’t matter, but it’s been somewhat annoying, and it makes it really hard to trace the data flow if you’re hunting a problem inside Nifty (because the IDE can’t tell you what pieces of the code access the x property if it’s not a member variable, and finding all “x” strings inside Nifty is going to find a lot of false positives).
Plus Nifty shunts every event through EventBus. EventBus would actually be a useful way to decouple control events from application activities that they trigger, but Nifty instantly defeats that purpose by forcing addressing the events to be addressed by… Nifty ID. There’s no way to have a button and a drop-down menu entry generate the same EventBus event. Event handlers for Nifty-generated events are supposed to be constructed via Nifty - so it’s not even decoupled from Nifty being the GUI library.
TonegodGUI has none of these problems.
That’s partly because it’s new (all software grows warts over time), and partly because it’s integrated into JME so it requires less interface handholding, and partly because Chris has built GUIs in the past, is asking questions, and is listening.
I can’t yet vouch for TonegodGUI’s stability in practice because my code isn’t running yet, but all questions have been answered with FAR simpler solutions than I had ever expected to hear.
Kudos to Chris!
@pspeed UIDs have been discussed, and I think there’s a vague consensus that they should indeed become optional.
Since it’s annoying me I think I’ll submit a patch for that soon 
@pspeed said: I'm just a curious observer but I still understand why UIDs are required at all. I can see how a UID could be used to match stuff up from XML (where you can't have the actual object references) but then it seems like it could be an optional attribute for that use case.
@toolforger said: @pspeed UIDs have been discussed, and I think there's a vague consensus that they should indeed become optional. Since it's annoying me I think I'll submit a patch for that soon ;-)
A waaaays back, I was considering doing away with them completely and making this an internal issue… however, when I posted the possibility of this being changed, I found that everyone who was currently using the library was making use of them + screen.getElementById(); Now, I’m not sure if this was leftover habit from using Nifty or not… but some of the more recent examples of how it is being used tell me otherwise. I’m hoping the util class I just added with the getUID() method will make life easier for those who are not using the IDing system.
shrug… other than the XML case, I guess I haven’t seen a valid use-case for them other than bad behavior.
Maybe you should work from the other side of it and collect specific reports of where “all elements having a UID” is required. Considering that the vast majority of UI toolkits get by without this, I suspect there will be none.
I would prefer keeping the uids, even if they can only be set through a setter method, but, it wouldn’t be a huge problem if they were totally removed. So feel free to change if you feel it’s better.