My last response in here on this, but I'm not a fan of FengGUI. I think it does a moderately good job of rendering, but I can't stand the API. It seems very hacked together and not well thought out. It also had several rendering issues when I was working on it with Galaxies Beyond. I might consider BUI, but FengGUI is no longer an option in my book.
Don't worry about it being offtopic.
Here are my thoughts on the gui-libs I've tried with jME:
- Swing/JMEDesktop: Problems on macintosh (could not get it to even show up with substance applied), not acceptable. Also, it eats a lot of CPU, but that wouldn't matter for Mad Skills Motocross since I don't need gui inside the actual game. Wasted one week here.
- FengGUI: Not quite ready for production use IMHO, buggy. Key traversal severely messed up. Don't like the API. Fast and responsive, though. Wasted one week here.
- BUI: Slow and lagging demos. When I quickly move the mouse, causing many mouseovers and mouseouts, the highlighted widget is like three steps behind. Mouse gets sticky on scroll bar button sometimes (controlling the scroll bar even though the mouse button has been released).
- Home-grown: Made in one week. Only the widgets I need right now. Will take one week for the next game as well, since appearance is not very separate from functionality. Limited layouts. Very responsive and easy to put nice effects on (scaling, moving, colouring). Quite fast. jME all the way, no opengl calls.
I should have rolled my own from the beginning, seeing as I only need a few different widgets. It would be a pain for anything more advanced though.
In my mind, this is jME's greatest weakness right now. FengGUI has potential, but it is not integrated very well (at all) into jME's scene graph.
To contrast… :P I like FengGUI a lot. It follows a lot of the same conventions as Swing and in my opinion has a lot of good and workable parts to it. When I started in on our GUI system at work a year or so ago it was not really ready for me to use, but I definitely studied and borrowed some of their techniques (along with Swing which again is quite similar.) I definitely went my own way in several areas, especially to improve performance for complex UI, but I would still recommend FengGUI as a good starting point or beginner's API.
I have not used BUI so no comment there… I initially used our JMEDesktop stuff, but Mac input issues and a few other needs (again this was a year ago) made that not an option for me as well.
renanse said:
To contrast... :P I like FengGUI a lot. It follows a lot of the same conventions as Swing and in my opinion has a lot of good and workable parts to it. When I started in on our GUI system at work a year or so ago it was not really ready for me to use, but I definitely studied and borrowed some of their techniques (along with Swing which again is quite similar.) I definitely went my own way in several areas, especially to improve performance for complex UI, but I would still recommend FengGUI as a good starting point or beginner's API.
I know you love to "contrast" me. :P I have not found it very similar to Swing when you get very deep into it. I would like it more if it were closer to Swing.
Tobias said:
4) Home-grown: Made in one week. Only the widgets I need right now. Will take one week for the next game as well, since appearance is not very separate from functionality. Limited layouts. Very responsive and easy to put nice effects on (scaling, moving, colouring). Quite fast. jME all the way, no opengl calls.
I should have rolled my own from the beginning, seeing as I only need a few different widgets. It would be a pain for anything more advanced though.
In my mind, this is jME's greatest weakness right now. FengGUI has potential, but it is not integrated very well (at all) into jME's scene graph.
This is where I'm annoyed...I hate everyone ending up having to "roll their own" GUI for their games. If you had done your work in LWJGL I'd see if you'd be interested in collaborating for an API, but as it is I think your work is useless to me. :P
I agree that jME is really lacking in the GUI side and that is one place where it could be much better. Hopefully this will change in the near future.
First sorry for discussing this in this thread, but it already started so … 
darkfrog said:
This is where I'm annoyed...I hate everyone ending up having to "roll their own" GUI for their games.
Yet you want to create your own GUI :)
I think FengGUI ist not that bad, and surely it a good start.
Why not work with them and try to fix whats missing or maybe change the API on a few things.
I only used FengGUI for a few Buttons yet but i think its nice and easy to work with.
And its completely customizable too.
Oh and Mad Skills Motocross is simply awsome, keep up the good work !
Core-Dump said:
Yet you want to create your own GUI :)
I think FengGUI ist not that bad, and surely it a good start.
Why not work with them and try to fix whats missing or maybe change the API on a few things.
Well, to be clear here I've actually talked to FengGUI about some ideas here and we decided that we couldn't really get to where I wanted. :)
The idea is to write a single API that anyone can use rather than everyone having to write their own implementation specific to their game. BTW, it's obviously not just me that has a problem with the available options. There have been several people that have complained similarly about why they aren't using the choices currently available.
This is the same situation that drove me to develop JGN and as a bonus in this situation I already maintain jSeamless, which this situation is a perfect scenario for an implementation of it. I would be happy to use JMEDesktop, but the performance impact is just too much since I need so much in-game interaction.
Well, another option is to make a fork of FengGUI, after all it is GPL, right? Something lake this happened also to BUI creating the fork gBUI (which I proposed to call Liana -monkey swing- ;)).
All in all, I agree that jME is lacking in GUIs, and volunteer to help as much as I can if it is decided to go in a coherent direction.
I would definitely not be opposed to pulling in from projects such as BUI and/or FengGUI, but I definitely want to start fresh and not be held down by pre-conceptions made in those frameworks.
In the next couple months I'll probably post more about this as the need grows and see how many people are willing to help such an endeavor.
i'll help as time permits.
now stop hijacking this thread 
nice work tobias. keep up the good work 
irrisor said:
@mojomonkey/renanse: we are still lacking moderator rights in here - can you split this into a new thread (couple of posts back), please
Split... It did not like me picking specific posts to split, so sorry, about 2-3 posts were lost at the beginning of the divert. :(
Well, good luck people…
While it's easy enough to create something for your own needs that looks somewhat impressive, I think what's really hard is maintaining it and making it attractive and adaptive enough for other to people to use. Once they see feature X is missing or feature Y is done differently from how they want it, it's very easy for them to travel the exact same road as you did, cause it's just as easy for them to create something for their own needs that looks somewhat impressive.
Unless you want to spend your time on extending and maintaining your GUI library to accomodate the needs of others (instead of working on, let's say, working on your own game) then I think you'll be no more succesful then what's already out there, and what's deeply burried attic of jME's CVS archives.
If this was in response to me: I assure you that I didn't mean to push my own gui library as any kind of solution to the gui problem. This is a quick and dirty one-time solution for this particular game.
Regarding jSeamless: A gui library based on LWJGL would be nice, but I would much rather see one that is integrated into jME's scene graph, so that you can use controllers and particle emitters and other jME stuff on the gui. jSeamless is a great concept, don't get me wrong, but jSeamless on LWJGL is not a solution to jME's gui problem. IMHO of course :)
llama said:
Personally I'd like to see a little innovation, something 3D and jME oriented rather than a copy of all the 2D gui APIs already out there.
I have really considered adding optional "depth" support to jSeamless when I got around to the OpenGL implementation.
llama said:
I think we've had enough also-ran 2D based GUI's in the past, based on someone's personal idea of what an api should look like. While it's easy enough to create something for your own needs that looks somewhat impressive, I think what's really hard is maintaining it and making it attractive and adaptive enough for other to people to use. Once they see feature X is missing or feature Y is done differently from how they want it, it's very easy for them to travel the exact same road as you did, cause it's just as easy for them to create something for their own needs that looks somewhat impressive.
Unless you want to spend your time on extending and maintaining your GUI library to accomodate the needs of others (instead of working on, let's say, working on your own game) then I think you'll be no more succesful then what's already out there, and what's deeply burried attic of jME's CVS archives.
Well, considering the idea of this implementation extends beyond the scope of game development at all it will be much larger and more complete than any implementation to-date if I can ever get around to writing it. In fact, some interest from another company has been expressed in funding the development, we'll see how that goes. The idea here is to develop a UI alternative to Swing in OpenGL for applications and then also gain the benefits from that in game development as well.
Tobias said:
If this was in response to me: I assure you that I didn't mean to push my own gui library as any kind of solution to the gui problem. This is a quick and dirty one-time solution for this particular game.
Regarding jSeamless: A gui library based on LWJGL would be nice, but I would much rather see one that is integrated into jME's scene graph, so that you can use controllers and particle emitters and other jME stuff on the gui. jSeamless is a great concept, don't get me wrong, but jSeamless on LWJGL is not a solution to jME's gui problem. IMHO of course :)
No doubt he was referring to me. :)
I was afraid you'd say LWJGL would not be as beneficial as one in jME. I'm hoping I can get good interaction with jME without having to make it tied to jME (obviously for the above mentioned reasons). When this actually comes about I'll probably want your input further on the limitations that would be imposed by not using jME directly to see if we can create some work-arounds.
Tobias said:
If this was in response to me: I assure you that I didn't mean to push my own gui library as any kind of solution to the gui problem. This is a quick and dirty one-time solution for this particular game.
No, in fact, I meant the opposite. You proof that it's very easy to quickly develop a custom solution, rather than to adapt a current GUI system to do what you want. My point is any GUI library would need very active maintaince rather than someone's favorite style op API to be succesful.
Of course the very reason that that's hard to do (we'd rather work on our games) is also the reason to have a good GUI library in the first place (we'd rather work on our games). So I don't want to discourage anyone from trying :)
The benefit here is that working on jSeamless is the majority of my day job these days. 
No, in fact, I meant the opposite. You proof that it's very easy to quickly develop a custom solution, rather than to adapt a current GUI system to do what you want.
Ah, yes. I see your point, and I agree. Wish I thought of that before trying to squeeze a few fancy buttons out of a gui lib that can do a thousand things but not exactly what I want. Now, if it was a space trading game (or other gui intensive game) I were developing, I would have been in far deeper trouble :) .
this is something taht seems interesting, but not really sure what a good UI design entails. Where are you guys getting ideas from? What would a good UI API include?
A gui library based on jME only? So this would be a chance to start from scratch and let it be influenced by the experiences made with all the other gui libraries. The first step would be to make a proposal of what should be in it. It should be lightweight and customizeable. I would love to help with such a project.
From the developers perspective, this gui libraries interface should be just like Swing, because that's what we all know. Maybe it should even use Swings listeners. The only problem i see would be 3D layout managers :-o (btw. are there any with BUI or FenGUI?)
A gui editor would be a good help to get the library popular then.
It would be best, if this library would get a part of the jMonkeyEngine itself. Is there any concept here for incubator projects?