SDK widgets too small for font

I’ve just installed jmomkeyplatform on Debian Linux with GNOME 3 and there’s a problem with the SDK’s GUI. Most of the widgets are too small for the font. Width is OK, but they’re not tall enough. It looks as if whatever’s calculating the widgets’ sizes is failing to take descenders into account. The text in buttons is placed below centre and in other widgets the text is cut off at its base line. And when I created a folder for storing projects at start-up more than half the text was missing from the bottom where I entered the filename.

I tried vanilla Netbeans and that looks like it doesn’t have this problem; I expect it’s a bug or incompatibility in the JDK etc bundled with jME-SDK. Is there a way to make jME-SDK use either my system’s openjdk7 or the one bundled with Netbeans?

Alternatively, is there a downside to installing the jME plugins in an independent version of Netbeans, other than it being a bit harder to setup?

Probably an issue with the linux LAF, try using the normal java LAF:

Edit: Installing the jME plugins in netbeans is probably not a good idea as you’re making all java projects jME projects this way.

Changing LAF does improve it thanks, but there are still a few widgets with slightly cut-off text, and the GTK-style widgets look nicer IMO.

I probably won’t be using Netbeans for anything else, so I wouldn’t worry about it being locked into jME if that’s the only problem. I’ll hopefully be spending a lot of time developing with it, so I think it’s worth spending a bit of time making it look nice :-). And I’ll want to use a vi plugin FWIW.

@realh said: Changing LAF does improve it thanks, but there are still a few widgets with slightly cut-off text, and the GTK-style widgets look nicer IMO.

I probably won’t be using Netbeans for anything else, so I wouldn’t worry about it being locked into jME if that’s the only problem. I’ll hopefully be spending a lot of time developing with it, so I think it’s worth spending a bit of time making it look nice :-). And I’ll want to use a vi plugin FWIW.

But the LAF is part of java, not of NetBeans, you’d have to use OpenJDK then.

OK, I found out how to make jME-SDK use the system JDK (openjdk7) and that’s fixed the issue with the native LAF for me. 8). Thanks again for your help. I think I’ll be fine with that JDK, it’s worked flawlessly for me with Eclipse/ADT even though the web is full of warnings to stick with Sun/Oracle.

@realh said: OK, I found out how to make jME-SDK use the system JDK (openjdk7) and that's fixed the issue with the native LAF for me. 8). Thanks again for your help. I think I'll be fine with that JDK, it's worked flawlessly for me with Eclipse/ADT even though the web is full of warnings to stick with Sun/Oracle.

Just don’t update it then. OpenJDK breaks every fortnight.

The Debian packagers are probably doing a good job of weeding out bad updates then. I think I read that openjdk6 was a poor relation to Sun/Oracle, but that openjdk7 is better and shares a lot more code with Oracle.

@realh said: The Debian packagers are probably doing a good job of weeding out bad updates then. I think I read that openjdk6 was a poor relation to Sun/Oracle, but that openjdk7 is better and shares a lot more code with Oracle.

The thing is that using OpenGL from java is relatively serious low level stuff and that the JDK also does some serious low level stuff. Its not that java apps would break per se but you do get native crashes with combinations of the JDK and graphics drivers every now and then.

OK, I’ll bear that in mind. Easy enough to switch it back if I have problems and/or for release builds.

@normen said: The thing is that using OpenGL from java is relatively serious low level stuff and that the JDK also does some serious low level stuff. Its not that java apps would break per se but you do get native crashes with combinations of the JDK and graphics drivers every now and then.

Been using the uptodate openjdk for some while now, and not getting more crashes than before I must say. Only downside is that it seem to be even worse with collecting directmemory.