I have pulled down JME3 and wrote a quick ant build so I can quickly compile for use with GBUI. I've found some things are the same, and quite a few are different.
The good news is that there are only 53 errors and one warning after doing some work with the imports - however, that does not mean that GBUI will actually work after I fix any of that.
What would be helpful would be some sort of cross-mapping, if you will between things between JME2 and JME3 - e.g. DisplaySystem is now xyz
I'm going to imagine that there isn't any way that this is going to help and that the port of GBUI from JME2 to JME3 is going to be a pretty big jump in code. That means that I may have to rewrite quite a bit of the system or just start from scratch. As it is, I'm going to have to relearn the engine in order to make fixes to GBUI that will hopefully run correctly, but isn't guaranteed.
I fully anticipate that there will be a lot of work in the next months to fully diagram and run through GBUI to document what's there and how it's currently operating as well as figure out what JME3 now does.
Starting over also means that there are a lot of bugs that are going to creep up.
I'm going to trodge on through and see if I can, at the very least, get the code to compile and then see if I can get the displays to come up.
I'm also going to discuss with the team the possibility of rearchitecting the entire framework.
Great to hear that, a good GUI system for jme3 is an absolute must. Maybe you will still encounter some changes within jme3 until alpha, but I think most things should stay the same… The package name will surely change soon, so be prepared for that 
I think you're overcomplicating things quite a bit… Instead of worrying about DisplaySystem, maybe you should just try attaching some GUI nodes to the rootNode while you copy one of the tests. I can't imagine how a GUI system would require this kind of low-level access to the engine.
I can't overcomplicate what's already there, only presenting the facts as they exist in the project.
The DisplaySystem in JME 2 and before is where the RenderContext (created by the method getCurrentContext()) as well as the Renderer states lives in addition to the width and height of the display, and from the Renderer, there are the factory methods createBlendState and createZBufferState
Some of this can be extracted out, as the majority of the references are width and height and those can be set elsewhere, like in BComponent.
Other references I've figured out, not all of them, yet, but most of them.
Believe it, or not, GBUI also accesses some lower level OGL which includes doing some manipulation in drawing lines, borders, backgrounds, labels, and some manual translations, pushing and popping the matricies directly and even some scissoring.
The OGL stuff isn't a concern as much switching between lwjgl and jogl as this can be extracted generically.
Well, you already talked about a possible reorganization. The most important part in my opinion is the layout manager and its possibilities. This is the core of the GUI system and what needs to be brought in shape for jme3. How exactly images, quads and color etc. are displayed is another thing which is of course system dependent. Still I think that if you need to access low-level lwjgl functions right now that is in fact not a good thing and we should see why that is so and how it can be avoided. (extending jme3 functions, do things different…)
Well I don't see the reason for low level accesses as well, basically you could do nearly everything with just colord/texture quads/circles/text2d in orthomode that have support for typical mouse events.
I checked the source code myself and I don't think that much work is needed. I might as well port it all myself, could take at most 2-3 days…
@Momoko_Fan - Do whatever you feel is best, if you think it's going to take you less time, then so be it
- OGL calls were done back in JME 1, I can tell you what they do, don't know why it was done at that time, don't care - they exist - maybe it was something when BUI was written pertaining to the pre JME1 releases that they had to do it this way, maybe it was faster making lower level calls, doesn't matter to me.
- I don't disagree that lower level calls shouldn't or couldn't be done, and that the GUI should be more "independent," but that is not the case. If lower level calls speed up the display, then - by all means - they should be there - albeit abstract so it's not dependent upon one OGL system…however, until last year LWJGL was the only system supported - and one of the things on the list is to refactor that set so that it can support whatever the OGL system chosen is.
- I never said much work was needed, only mentioning the options I've looked at after spending a whopping 15 minutes with JME3 and GBUI - being the PM means I still have to consider what the devs have seen and/or are looking at. I don't just make a decision b/c I can. GBUI is a community project, the developers and users drive what gets done and when. The decision to look into JME3 with GBUI was made and I posted my initial findings.
standtrooper said:
@Momoko_Fan - Do whatever you feel is best, if you think it's going to take you less time, then so be it
Would it be possible, if you posted what you have right now as an SVN branch, and gave me write access?
My googlecode username is "shadowislord".
standtrooper said:
1) OGL calls were done back in JME 1, I can tell you what they do, don't know why it was done at that time, don't care - they exist - maybe it was something when BUI was written pertaining to the pre JME1 releases that they had to do it this way, maybe it was faster making lower level calls, doesn't matter to me.
2) I don't disagree that lower level calls shouldn't or couldn't be done, and that the GUI should be more "independent," but that is not the case. If lower level calls speed up the display, then - by all means - they should be there - albeit abstract so it's not dependent upon one OGL system...however, until last year LWJGL was the only system supported - and one of the things on the list is to refactor that set so that it can support whatever the OGL system chosen is.
It isn't a problem, I know what they do and so do you, but they can't stay if GBUI is ported to jME3. Note that the reason why they were there in the first place might be because jME1 did not support certain features that were required. In that case, I can add the needed features to jME3 if necessary so no GL calls are needed.
Momoko, you really want to open a new field of work for yourself? 
Standtrooper, I'd say a new branch would be good, maybe you can even make enough changes already so that momoko doesnt want to work on it anymore 
Did anything ever come of this ?? GUI is one of the most important aspects of my app and I would be very willing to pick this up if no one else is working on it, especially since banana-peeler already exists as a gui editor, and the nifty editor is still WIP.
Last I heard, GBUI development (as a whole, not just for jME3) came to an unfortunate halt because standtrooper ran into some unforeseen trouble. By all means get in touch and see what you might do to help.
Yeah, sorry, I've been out of contact for a while. I was two weeks away from a GBUI2 release when my local svn server and almost all of my film equipment was stolen. I've just received my laptop replacement and am still waiting on a replacement server. I'm currently trying to document all of the changes that I had made, which are in handwritten and modestly typed notes that are all I have left since all of my external drives and backups were stolen.
So, right now, I'm just getting back to figuring out the state of the local svn server based on the notes i've been able to compile from the developers working on the project.
After almost 3 months of hiatus we're going to be getting back into the swing of things.
@ascendion if you're interested in joining the OSS team, let me know, I'll have plenty of work coming up in the next few months in pushing to JME3 and then making new changes that will be reverse merged to JME2.
Since I'm still not at full capacity with my hardware I'm playing catchup on all of the projects that I've borrowed hardware for all over the place and trying to get developers/editors back into the shop so I can get these video projects and software projects out the door.
I'm here and I got the time – I'm stalled until MF, Normen, and I thrash some ideas for the state and rendering system. I need a gui that has a decent gui editor because I'm a lazy scuz that hates designing visual stuff by writing XML
I've got your current code loaded up and have pared down a lot of the compile errors, but I don't know enough about the engine to know how to fix some parts… all I will probably need is a few pointers to explain how things changed and where similar functionality is in jME3 – then I can run with making the fix. I've got an SVN server online if we need a place to work.
Ascendion said:
because I'm a lazy scuz that hates designing visual stuff by writing XML :)
Well standtrooper is working on gbui, how about you start working on the NiftyGUI editor in jMP instead of complaining about it being WIP :P ;)
normen said:
Ascendion said:
because I'm a lazy scuz that hates designing visual stuff by writing XML :)
Well standtrooper is working on gbui, how about you start working on the NiftyGUI editor in jMP instead of complaining about it being WIP :P ;)
Because I'm throwing together an implementation of the Element system so we have something to point at and say whats wrong with it :)
(You probably don't want to hear this, but I'm seriously considering making a GUI library and editor based on the Element system if we can come to an agreement on how elements will work)
Ascendion said:
(You probably don't want to hear this, but I'm seriously considering making a GUI library and editor based on the Element system if we can come to an agreement on how elements will work)
Well I dont mind, we take whats good, but we wont let jme3 become the multiheaded beast it was in the jme2 days with mutiple GUI libs that all would not work properly ;)
Considering that the GUI is a major facet of my app, I wouldn't be stopping until it worked right But that is down the road a bit. I am currently trying to deal with a huge disappointment. Java generics are crippled and I'm still working on getting the generic singleton loader to do what I want. Thanks to type erasure, I cant have a generic singleton of a generic factory because static members of a generic are common to all the "derived" versions of the generic.
Refactoring !! :x
Ascendion said:
Considering that the GUI is a major facet of my app, I wouldn't be stopping until it worked right :) But that is down the road a bit. I am currently trying to deal with a huge disappointment. Java generics are crippled and I'm still working on getting the generic singleton loader to do what I want. Thanks to type erasure, I cant have a generic singleton of a generic factory because static members of a generic are common to all the "derived" versions of the generic.
Refactoring !! :x
xD I guess you have to get a bit into java here