No worries, I shout at everyone. 
My post wasn’t directed at anyone in particular.
Yes. Figure it out and write documentation for the next guy. Give back to the lib.
scene2d should be nice and clean. What part of scene2d is a rough spot?
I’m fairly sure that JOGL does applets too. But, you know, … why bother with two nearly orthogonal bindings to OpenGL.
Well done Sun! Divide and conquer.
Cas 
Why not just take the comments about documentation as what they are ? Invaluable feedback about your work.
Please don’t fall into the trap of pure knee kerk justification. Listing another 10 points of existing doc wouldn’t help if users are telling something different.
I am not a noob either, know what I have to invest and am able to judge things pretty objective. That’s why I do recommend using LibGdx.
There are problems in the implementation, things to improve, but calling given feedback as insane lowers the motivation of giving anymore tremendously…
And yes, the UI stuff isn’t the clearest.
I agree that the docs can always be improved. I think we are doing ok compared to other offerings, and once i have more time i’ll fill in the missing articles on the wiki. We sadly have no influence on the third party tutorials. That being said, the only aPi that changed is scene2d. What parts of the documentation should we focus on?
Concerning “problems in the implementation”: would you care to elaborate in detail. It’s hard to improve something just base on that little phrase.
Feedback has to be more specific to be useful. There are lots of docs that are not outdated. This is my point.
[quote]Please don’t fall into the trap of pure knee kerk justification. Listing another 10 points of existing doc wouldn’t help if users are telling something different.
I am not a noob either, know what I have to invest and am able to judge things pretty objective. That’s why I do recommend using LibGdx.
There are problems in the implementation, things to improve, but calling given feedback as insane lowers the motivation of giving anymore tremendously…
And yes, the UI stuff isn’t the clearest.
[/quote]
What about the UI is not clear?
My next project is going to be a telepathic issue queue. ;D
The only thing I miss in scene2d is an editor for themes. Anything else if simple as apple pie imho. scene2d does exactly what it tell and offers even more. I mean you have a comple action system (you can extend this for an event system so you can script some events and lets them run your story scenes). I love this 
IMHO what the lib really needs is a wiki that can be edited by users, so it’ll grow fastly enough to cover the changes. IMHO.
Of course JOGL supports applets. If there is something wrong in the JOGL backend of LibGDX, it has to be fixed.
scene2d itself is a nice clean API. The documentation is the rough spot. I figured most of it out from the source.
We fixed all Jogl related issues by deprecating the Jogl backend.
R.D., an editor would be neat. One issue is that in an effort to keep scene2d relatively simple, the styles generally just contain the images for a widget. Other features like text alignment and padding aren’t in the styles and is generally something that has to be customized via code.
ReBirth, we’re all for the community doing the hard work. The problem with a wiki is some of the quality can be low, the articles tend to not mesh very well, and few people contribute. If a handful of people would contribute many articles each, it would probably turn out pretty good.
What part of the documentation is lacking? I’m especially interested as I think it is pretty well documented. Maybe it needs more practical examples to go along with the relatively quick start-to-finish tour?
Having both a JOGL and an LWJGL backend is nice for the choice it provides, but also means twice as many potential bugs. Since libgdx abstracts the backend for most apps, most users don’t care for the difference. I personally find LWJGL’s API a little easier when I need to dig into it, eg for embedding in Swing. This is probably possible with JOGL, but I haven’t dug into it. As a result, the LWJGL libgdx backend has an easy to use OpenGL frame, canvas, multiple canvas with the same GL context, etc. Ultimately though, JOGL hasn’t seen updates and we haven’t found time to update to JogAmp, so deprecation makes sense right now.
So that’s the problem. I believe this was what happened to user wiki 
I think the tutorials on badlogicgame’s youtube are outdated…uses JOGLApplication to launch…or maybe everything else is the same…
Ok, I already mentioned the good, here is some of the bad I came across so far:
Setup/Deployment
3rd party libraries like LWJGL or JOrbis should not be bundled together with LibGdx’ own classes.
The benefit is small, potential problems are big if you get version conflicts if other libraries do the same or if you have to switch versions manually.
I had to downgrade OpenAL, upgraded LWJGL and had to remove duplicated JOrbis classes due to using Pauls’s SoundSystem.
Furthermore, attaching source code for gdx-backend-lwjgl.jar to both LibGdx and LWJGL is not (directly) possible with Eclipse.
Same is true for bundling and extracting native libraries. Core application files should be installed under one roof (except user data). No auto extraction.
For installing, the most simple solution is the best. Supply the path to the libraries. Clean and simple.
Each library should get auto generated build entries with date, time and version number.
I might be the first who is not using the official lifecycle stuff. Unfortunately, constructors of LwjglGraphics are not public, neither is it possible to create a LwjglInput on your own.
LwjglGraphics#setupDisplay is not public, etc.
It is ok to offer an easy-to-use setup and lifecycle, but people should not forced to use it, unnecessarily. I can assure you LibGdx works fine without
So, I had to take the ugly way, create a com.badlogic.gdx.backends.lwjgl package and move three of my classes into it.
Just upgrade the package scope to public. It is a framework, people are inventive of how to use it…
“Don’t be forced to use anything, pick and choose.”
I have to provide Gdx with a GdxApplication although it is just an empty class skeleton, a NullPointerException is the reply if omitted.
UI
I don’t understand the inheritance hierarchy of Actor. First of all, its long. Then, why is a Button a table ? Seems like widgets and layout are mixed up.
And if so, why are the other widgets like Label e.g. no tables ?
In my code to build a screen with a few centered button I put this line months ago:
button.padBottom(20); // oddly high value required
Without that the text was painted outside the button borders. At least it used to. Today with Libgdx 0.9.6 the behaviour changed.
Back then, I couldn’t figure out whether I was doing something wrong or whether it was buggy.
I have no idea how to convert an existing complex Swing UI into Libgdx.
Documentation
I started with “Beginning Android Games” which is quite good even though I still don’t have an Android device.
But I learned all need to know about OpenGL from it.
An updated version for Libgdx with all of its features would be nice (don’t know if its possible, I vaguely remember reading about some legal issues)
Eventually, there need to be complete (yes!) JavaDoc. The web site states it is full, which is, well not quite true.
There are too many places between you have to jump back and forth to find required information.
I did not find a history document listing all changes between versions.
Various
Feeding the sources to a dependency analyzer like JDepend shows a dependency mess only excluding 3 of all packages.
While not all shown dependencies are first level, there are cases like com.badlogic.gdx.math which relies on com.badlogic.gdx.math.collision
or com.badlogic.gdx.graphics needing com.badlogic.gdx.graphics.g2d
Pixmap seems to be more generic than Gdx2DPixmap but in fact it messes a lot with Gdx2DPixmap.
Generally there should be no dependencies pointing deeper into the package hierarchy, only the other way round.
This is very important for a library design. For the ongoing development when LibGdx evolves and grows, for splitting into modules and choosing only parts to use, to prevent from becoming an unmaintainable monolith.
There are a lot of public fields which is owned AFAIK to the slow nature of Dalvik. I never messed with Android, so I can’t really argue against it. But it’s not nice. From looking at it, the information you get is “so all of this is being modified from all places of the library”.
Methods with 17 (!) arguments are just unusable.
We made that decision early on. For 95% of our users it makes live a lot easier.
See above.
That’s a good idea, i’ll add that if i find the time.
We can’t anticipate all funky use cases of course. The only assumption we make is that you use Application and ApplicationListener. XNA is a framework as well, i’d like to see how you can rip out such a part from it
Furthermore, we try to keep the public API as slim as possible. Exposing internal methods is bad (both public and protected), we might change things in the future, people will cry rivers if their stuff breaks.
Because Buttons are composite widgets with children which need to be laid out (e.g. labels, images etc.).
As announced on the blog and twitter multiple times (our only way to get info out to folks), the scene2d API changed quite a bit. We generally do not break APIs, in scene2d’s case we made a big exception. We were diligent to inform everyone of this change.
Also, bugs get fixed occasionally, i hope you don’t hold that against us
Not exactly something we can help with. I have no idea how to convert a complex Swing UI to QT, wxWidgets, Tk etc. either.
The book has nothing to do with libgdx. Granted, the framework developed therein looks familiar, but that’s about it. A book of similar scope using libgdx is out of the question.
Ya, working on that ourselves and via 3rd party pull requests. Again, we aren’t doing to terrible compared to similar offerings. Which is not to say we won’t invest more time in making it better.
Not sure what to say to that. That’s the nature of big APIs i guess?
We list those on the blog, giving an overview. We also have release tags in the SCM repo, if you want to know the exact details you can run through the commit history.
Various
Yes, there are some dependencies that i’d like to losen up. However, the mantra that a package shouldn’t rely on a deeper package just isn’t always applicable nor useful. I’m 100% certain that math doesn’t rely on g2d, unless someone else (NATE) did a bozo. Pixmap is a wrapper around Gdx2DPixmap so we aren’t dependent on the concrete JNI APIs of Gdx2DPixmap. Changing native methods has a cost, changing wrapper methods is trivial.
Yupp, we try to reduce those one by one were possible and were performance on Dalvik won’t get hurt. There are still tons of 2.x devices out there, and all suffer from poor method invocation performance. We do sacrifice cleanliness for performance on Android.
Agreed, which method are you refering to?
Thanks for taking your time writting this up. I’ll try to incorporate a few of your suggestions as time permits.
Absolutely understand and agree with that statement. However, as I’m in the 5%, I ended up forking about 20 classes from the GL stuff (SpriteBatch, Mesh, Shader, FBO, Texture, etc.) and refactoring to call LWJGL directly. There’s definitely the potential for a lightweight and useful LWJGL util library in there! Also might offer a good middle ground for the OP.
Sounds like a weird mantra to me, but then I’m used to working with module systems (NetBeans platform, OSGI, etc.) Doesn’t seem unusual to use sub-packages to provide API’s or tidy up implementation code, particularly when you’ve got a good way to control package visibility.
I don’t get it. What is easier, deploying 1 instead of 3 files ? The introduced problems are far bigger.
That’s what users are good for: pointing to new possible use cases. And that’s what designing libraries makes it so difficult.
Making the described methods public does not expose anything dangerous, it just extends the usability of LibGdx.
Yes, but why only buttons, seems not consequent to me.
For example, math relies on utils which relies on g2d.
Utils should be splitted.
If Pixmap is a Gdx2DPixmap wrapper, just move into the g2d sub package.
To me, deeper packages are more specific than higher level packages. Thus, no pointing down.
But the real problem are cyclic dependencies. Those can and should always be removed. As you cannot cut the way from nested to upper packages, it can only be down as mentioned.
Another example: math.collision offers stuff for a a special use case, but math should be deployable without that, which is currently not possible.
Sorry, don’t remember.
Btw, Blog, my contact lenses are no good any more but I think there is no link to the blog.
I think, its time to get me a Nexus 7 as my first Android play thing and see how it’s doing with programming
I am willing because I love LibGDX (I’m crazy like that, I actually like to write documentation), but I still have to complete at least one game before I consider myself qualified to be of service 
Thanks for that nice overview of stuff to look at though, it is incredibly helpful.
As mentioned, a button is a composite widget. It is a table with up/down/over/checked/disabled states and corresponding background images. Because it is a table, you can put anything in it: label, image, image + label, etc. You can align the contents in 9 directions and do the other flexible layout stuff that table can do. Other widgets are not tables because they are not composite widgets and don’t need the layout flexibility provided by table. You don’t put other widgets in a label or selectbox. Also, there is nothing wrong with using a container for layout.
It appears only one class in utils (ScreenUtils) uses g2d and should probably be moved into g2d (and this wasn’t my fault, yay!).
Packages are for organization but have no rules. The rules that you made up are fine enough, but I don’t think they would really have much of a tangible impact. I’m all for organizing things cleanly, but your rules seem a bit strict.