if you have your own component and do something like :
g.setColor(0,0,1,0.3f);
g.fillRect(0, 0, width, 100);
you'd expect to clear everyting with a transparent background right ?
Instead the background gets more and more blue until everything is completely blue.
JTextfields.
If you have a textfield (in, example, a chatarea) and you move around to other applications, you will suddenly not be able to type anything
in that textarea until you have restarted you app.
You can't set a transparent background on textcomponents, like JTextArea. The same thing will happen as in 1), in the beginning it will be transparent but
very soon the chosen color will be rock solid and you can't see through anymore.
Generally theres small problems, like buttons and other components not showing up every 4th time you open the app.
It's well known that swing is pretty "strange" (though very nice to program with) so it might not be a JME problem.
it depends on the composition mode. (Additionally there's a bug with clear/fillRect in some jdk versions). I think the current behaviour you described is the correct one (becoming more and more blue) if the component is not opaque.
strange - you'll need to debug it a bit to find the cause for that (never heard of that before)
hmm, does it work in other swing apps with a transparent JDesktop? If not it's probably not supported by those components… but I think I have seen half transparent chat areas in screenshots on this board, so probably you're doing something wrong?
Probably you did not create/show/alter them in the swing thread?
Try playing with the opaque setting on your stuff. Some components need to repaint entirely to get the real background colour up rather than the optimized colour afaik.
Are you using more than one desktop? I've seen issues with focus-grabbing stuff in general.
Stuff like (1)
When the JDesktop updates its bitmap there's a set amount of time to repaint before the updated texture (which was either fully or partially flagged as dirty) is then flushed onto the GFX card in the ImageGraphics used. I guess this is to limit the maximal framedrop possible when doing heavy repainting. You can probably manually trigger it if you like - at least there's a getGraphics function there.
Also, be sure to update any swing-stuff in the swing/awt thread rather than from the outside.
Thanks for your input everyone, didnt have time to look at it before now…but now I have to fix these problem somehow (cause they
drive me mad).
Ive been working with swing many years and it has always been a major pain with things
that none can explain constantly attacking your application. Well, since its more or less the only gui for java or at least for Jmonkey it would
be cool to make it work right.
1) if you have your own component and do something like :
g.setColor(0,0,1,0.3f);
g.fillRect(0, 0, width, 100);
you'd expect to clear everyting with a transparent background right ?
Instead the background gets more and more blue until everything is completely blue.
Fixed with hacks, just use "clearRect" instead. Can only have black bg color then.
2) JTextfields.
If you have a textfield (in, example, a chatarea) and you move around to other applications, you will suddenly not be able to type anything
in that textarea until you have restarted you app.
This only happens of I leave the applicaion via ALT TAB (which i ALWAYS do). If you use the mouse to click to another app, it works.
All JTextfields are dead after. This is really the biggest issue right now for me..it's awsomely annoying :)
If you want to see it happen, download the app, http://onlineboxing.net/ob3d/download/ (just ignore physx u dont need it to test this).
3) You can't set a transparent background on textcomponents, like JTextArea. The same thing will happen as in 1), in the beginning it will be transparent but
very soon the chosen color will be rock solid and you can't see through anymore.
No solution..
4) Generally theres small problems, like buttons and other components not showing up every 4th time you open the app.
It's well known that swing is pretty "strange" (though very nice to program with) so it might not be a JME problem.
Maybe there's some workarounds for these things ?
I create everything in the swing thread now using SwingUtil.invokeLater()..and from that thread I call my buildGui, for example.
Still sometimes textfields, buttons etc just dont show up..
Last thing I noticed: you have to create ALL your userfaces on startup..at least all you JMEDesktops states..you cant create them on "the fly".
No biggie just makes everything a little more unhandy, and "easy" should be the slogan of JME.
PS I know about FengUI as well but I think most Java programmers would still prefer Swing despite it's annoyances..also nice layout managers
like substance make everything looks more "gamish" right away..
You probably already know this but I found out that the desktop still receives
keyboard and mouse events even when you don't see it on screen (gamestate is inactive).
So when you switch from desktop to desktop (or just from any other state to the desktop) all kind of "garbage" appears in textfields, buttons have been clicked etc.
What I did was to disable the desktops inputhandler whenever the state the desktop belonging to was inactive…then it worked perfectly.
Wow, after long searching a bug in my app i finally stumbled on this post and found a cause i would never have thought of:
If you leave your JME-App containing a JMEDesktop by using ALT-TAB all JTextFields no longer accept any input.
I couldnt try yet but i'm sure this can be reproduced with the TestJMEDesktop. Did you think about fixing this? I'm willing to contribute there as well but you would have to give me some hints at where to start.