Hi Zhe Wang, yes Spine is written using libgdx as the renderer for the editor tool that runs on the desktop. Of course the runtimes are written for each game toolkit, without anything specific to libgdx. By using libgdx everything is drawn by OpenGL at 60fps, so we can do smooth UI transitions and of course the animations render quickly. Also it means that the application looks and performs identically on all platforms. Many UI toolkits fail on this point and tend to not look terribly nice.
Spine makes extensive use of my 2D scene graph from libgdx, called scene2d:
http://code.google.com/p/libgdx/wiki/scene2dOn top of the 2D scene graph is a small library for developing UIs, called scene2d.ui:
http://code.google.com/p/libgdx/wiki/scene2duiThis adds is an approach to validating/invalidating layout. It also adds UI widgets, each of which is only 100 or so lines so are easy to understand, use, or even reimplement if necessary.
There is one last important piece which makes working with scene2d.ui pleasant, and that is another of my OSS projects called TableLayout:
http://code.google.com/p/table-layout/This makes layout code sane, which is extremely important. All of the Spine layout is done with TableLayout.
I’m not yet so familiar with cocos2d-x, but I understand that it is a 2D scene graph so should be possible to build a UI using it, similar to how scene2d.ui is built on top of scene2d. If it is too complicated on the lowest level, build less complicated layers on top until it is manageable. UIs have pretty specific requirements: layout (typically non-overlapping) including invalidation/validation to trigger relayout, events probably using a bubbling system, themeing/skinning the UI, etc. Implementing these major features will take some time and should probably be iterated and refined a few times before building something large on top. Getting scene2d.ui right was a lot of work, with multiple rounds of refactoring which had to break everyone’s code. Eg:
http://www.badlogicgames.com/wordpress/?p=2468In the end it was all for the breast, er best.
One feature that strikes me as being important is that you probably need a source code editor in CocosBuilder. This can be an absolute quagmire to try to do yourself. If you were using Swing, RSyntaxTextArea is quite nice, but Swing is a bit of a pig so I doubt you want to go there. If you are using C**, Scintilla is very, very good:
http://scintilla.org/SciTE, Notepad**, and many others are based on it.
Another option you can take is to use Eclipse RCP. This gives you cross platform and a great IDE feel as well as text editing capabilities. Eclipse uses SWT for a UI toolkit, which is a bit strange, but Eclipse is very impressive and probably has a LOT you could leverage instead of doing everything from scratch. RCP is a complicated beast though, so be prepared to do a lot of research when you dive in. It would be some effort, but you can drop down to C++ using JNI to implement whatever rendering you want, eg cocs2d-x. libgdx has something called gdx-jnigen which makes mixing Java and native code a lot easier. Or you could use libgdx for the rendering inside Eclipse, probably easiest by using a SWT->Swing bridge, then using libgdx’s LwjglCanvas to embed libgdx in the Swing. This way you’d be Java through and through, which will simplify your life greatly over using native code, getting the build to work for multiple platforms, etc. I know I’m converting you to a Java developer, but it does have fantastic tooling and cross platform becomes a whole lot easier.
Hope that helps.