@relucri : Hi , i’m working on the editor now but the fact is the progress it’s slow (i’m kind of busy at work) 
, and it’s good news that for some reason i can reuse much of your code.
After a long time struggling with the idea of a GUI Editor, I can layout the problem in 2 approaches, which answer the biggest question:“How can the XML tree and the Elements keep in sync?” in two different way.
Approach A) Let’s assume the user never want to look at XML anymore, cause they really have a good visual editor, the XML just the way to save the things. So this is a one way from Element tree serialize to XML tree whenever needed. And it’s your editor’s current approach. I have to say, it’s not too hard (mean I my self see no difficulty at the moment) to integrate into the JMP, so for Phase1 of integrated Editor, I will just port your code to the JMP … and leave it like so! ==I will explain the reason later.
Approach B) Editor’s user want to use XML(text form) and also the Visual elements when creating UI. That immediately require the 2 way <-> synchonization for every changes. In turn this kind of sync make the problem become big and 3x harder. Further more I have to say XAM API of Netbean is lack of documentation at the time I start writing something with the API like this Editor. Now is it worth the shot… mmm I don’t really know for sure. At some point I think: " f#k it, just forget the XML, let the user just use the visual things, we have embed control editor, have 9 patch editor, style editor, groovy scripting,… a lot features already…" .
And by this approach I have to change a huge amount of Nifty core for the sake of Editor friendly, for ex: hook into the Loader work flow in style of XMLLoadListener, hook into Creator, Builder to sync the XAM tree to the element tree.
It’s a huge amount of work, no joke!
That said I’m still considering between the two approach but it seems like I nearly take approach A because it’s maximize the reuse of your code at this moment and I see no hard work.
@relucri : I really open for your suggestions, because in fact, at first what I do almost is reusing your code and port into a Netbean platform code style for Netbean plugins enviroment. No big deal.
After that, I will add these feature:
- StyleEditor to edit Style and attribute
- ControlEditor to edit Control class and include declared Control definition into the main type tree. If it still mising, display empty box.
- As for a “real” Nifty input testing enviroment, I also have to write a closed box input handler for a Swing container. That means I want the element to get input event in the Preview window for real, but just kind of events I want to test out. That’s change JMENiftyDisplay class but may be I figured out how to implement it.
- Automatic GUI generation: Bean to NiftyElements and Layout, the same with what MetaWidget does for other Swing or GWT
- Convert existed Builder to XML, dynamic create GUI via GroovyScripting
Nifty core changes or additions: [ I’m still thinking about contact @void256 for these changes, I considered it’s a huge impact but … still thinking]
- More EventBus coolness…
- The hooks to cycle metioned above.
I added few GUI plugins, not just related to Nifty:
a) 9 Patch editor to extract info images (think : you don’t need to do imageMode your self)
b) Sprite editor, which can handle Sprite elements in a 2D style graph scene , (think Adobe Flash things) for JMP
c) Sprite compact, extract, texture atlas tool
======= Example for 3 above tools you can see at :
ShoeBox
http://www.aurelienribon.com/blog/
I made them cause I need them in JMP, you can use ShoeBox or GIMP or what ever you like
d) PTS,SVG importer for the sake of artist.
e) May be improve the Bitmap font editor
P/s: Sorry for a little GL game’s ads but it will be so kind if you guys can try : https://play.google.com/store/apps/details?id=com.gameloft.android.ANMP.GloftINHM . My team’s game
