What do you mean exactly? I need to do something like this in C/C++ in the method NewtWindows_setFullscreen in https://github.com/sgothel/jogl/blob/master/src/newt/native/X11Window.c. Do you think I could access this variable by using sun.awt.X11.XToolkit? Thank you for the tip.
Edit.: You’re right, I can even use sun.awt.X11.XClientMessageEvent and some other Java calls to do it.
Sounds like you might have the makings of a hacky workaround there then 
Cas
It is not very complicated, only between 5 and 10 lines of code to enter fullscreen mode and the same at exit by using XLibWrapper. Something like this workaround is already used both in LWJGL and in JOGL 2.0 (NEWT), the only difference is that I won’t have to write C code if I use XLibWrapper.
Hi!
The bug report in Oracle bug tracker is here and has been accepted:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057287
I cannot vote yet, something is wrong when I login.
Hi Julien,
Could I clarify whether you’re using FSEM or just trying to set the size of the window - your KDE bug report suggests you’ve tried both, but the Java bug report only shows the latter?
As per my comment here - http://www.java-gaming.org/index.php/topic,22661.msg187353.html#msg187353 and the linked to bug report, this is meant to be fixed! I haven’t used KDE for a number of years, but on GNOME using gd.setFullScreenWindow(frame); works correctly and sets the required _NET_WM_STATE_FULLSCREEN atom on the window already (this is on Oracle JDK not OpenJDK at the moment, but fairly sure it wasn’t a bug there last time I checked).
Best wishes, Neil
Hi Neil
I have succeeded in updating the bug report after trying during more than 2 hours. I have tried using both the simulated fullscreen mode and the fullscreen exclusive mode, both work everywhere on Linux except on KDE 4. I tested with Oracle JVM and OpenJDK. The required _NET_WM_STATE_FULLSCREEN is not set anymore if both case but it does not break anything on GNOME. I have not tested with 3D desktop (Kompiz, etc…). I reproduced this bug on Mageia Linux 1 but it can be reproduced on a recent version of KUbuntu. To sum up, Oracle does not respect the EWMH specification, I don’t know when they broke that. KDE 4 respects more strictly this specification and it fixed some problems on netbooks. I have almost given all elements to provide a fix in the bug report.
Don’t hesitate to ask me some other questions about this bug. I really do my best but if I don’t get enough votes, my bug fix won’t be integrated.
I have to be more precise. This bug affects only applications relying on the standard API, neither the LWJGL native windowing system, nor NEWT (JOGL 2.0). Is it clear now?
If you want, I can do some more tests on GNOME monday or sunday night. Someone close to me is waiting for something not related with computer science :-* Bye.
Well, won’t expect a reply anytime soon! ;D
Like I said, this works on GNOME for me so no need to test it. I’m on 6u24 until I can do a system upgrade next week, so I don’t know if anything has changed. It is following the EWMH spec for me - xprop shows right settings.
However, quick flick through the OpenJDK source suggests this code path might require XRandR. Do you have it installed? Found this through Google - https://bugs.mageia.org/show_bug.cgi?id=1680
If not this, then I’ve no further ideas …
Neil
I have no problem with GNOME, it was broken only several years ago (see Metacity bug). XrandR 2 is installed but not the package allowing to use it in command line.
Edit.: installing this package does not fix the bug.
Assuming you’re using the same install with GNOME then this seems really strange. You might try xprop on GNOME - for me this shows the right flags set. The OpenJDK source file I looked at earlier is openjdk/jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c - my download of the source is quite old now, but assuming it hasn’t changed then you could try getting the trace to print out - might point you in the right direction.
I have my own problems with GNOME and window hints mind you - modal dialogs sometimes cause the main window to disappear from the window list (thank goodness for Alt-TAB) - but that’s another story …
Best, N
Hi!
Actually, you’re right, I use the same install.
It is an excellent idea I will do this at home. I’m going to look at the source code.
[quote=“nsigma,post:14,topic:35027”]
I didn’t know this one, thank you for this piece of info.
Edit.: In the source code, in 2007, it worked properly, I looked at this:
http://icedtea.classpath.org/hg/openjdk/file/ce9dde984c21/j2se/src/solaris/native/sun/awt/awt_GraphicsEnv.c in X11GD_SetFullscreenMode.
Edit.: this is the current version:
static void
X11GD_SetFullscreenMode(Window win, jboolean enabled)
{
Atom wmState = XInternAtom(awt_display, "_NET_WM_STATE", False);
Atom wmStateFs = XInternAtom(awt_display,
"_NET_WM_STATE_FULLSCREEN", False);
Window root, parent, *children = NULL;
unsigned int numchildren;
XEvent event;
Status status;
if (wmState == None || wmStateFs == None) {
return;
}
/*
* Note: the Window passed to this method is typically the "content
* window" of the top-level, but we need the actual shell window for
* the purposes of constructing the XEvent. Therefore, we walk up the
* window hierarchy here to find the true top-level.
*/
do {
if (!XQueryTree(awt_display, win,
&root, &parent,
&children, &numchildren))
{
return;
}
if (children != NULL) {
XFree(children);
}
if (parent == root) {
break;
}
win = parent;
} while (root != parent);
memset(&event, 0, sizeof(event));
event.xclient.type = ClientMessage;
event.xclient.message_type = wmState;
event.xclient.display = awt_display;
event.xclient.window = win;
event.xclient.format = 32;
event.xclient.data.l[0] = enabled ? 1 : 0; // 1==add, 0==remove
event.xclient.data.l[1] = wmStateFs;
XSendEvent(awt_display, root, False,
SubstructureRedirectMask | SubstructureNotifyMask,
&event);
XSync(awt_display, False);
}
Edit.: The missing lines in /jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c are:
Atom wmStateAbove = XInternAtom(awt_display, "_NET_WM_STATE_ABOVE", False);
event.xclient.data.l[2] = wmStateAbove;
Atom types[2]={0};
int ntypes=0;
types[ntypes++] = wmStateFs;
types[ntypes++] = wmStateAbove;
XChangeProperty( awt_display, win, wmState, XA_ATOM, 32, PropModeReplace, (unsigned char *)&types, ntypes);
The previous code works on GNOME but not on KDE because KDE accepts fullscreen windows only when they are on top… and GNOME is more laxist.
@nsigma I remember now that a guy from the KDE team asked me to test with GNOME and the properties were not set. Thank you for pointing the good source file.
My reading of the spec would be that KDE is at fault here if that’s the case, but I’m no expert on this!!! The spec says that _NET_WM_STATE_ABOVE “should not be used by applications”, and the spec and the examples I’ve seen state that the _NET_WM_STATE_FULLSCREEN should apply to the focused window.
I have to speak about that to the KDE team.
Hi!
@nsigma You were right, on GNOME 2.16.1, the atom is set to the correct fullscreen test. It is then an old KDE bug as I explain there at the bottom of the page:
https://bugs.kde.org/show_bug.cgi?id=276159
My patch will be useless except if the KDE team refuses to fix it.
GNOME 2.16? You should upgrade! Confirm same result on 2.28.1
Sometimes people are too quick to blame Java (ie. comment #9 in your KDE bug report) - it ain’t always the problem! :persecutioncomplex:
A bit offtopic, I tried running your TUER jnlp using “javaws http://tuer.sourceforge.net/tuer.jnlp” on the command line, and Java threw an exception:
com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.1/webstart/jogl.jnlp
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCachedFile(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadExtensionsHelper(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadExtensions(Unknown Source)
at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
At home, I use KDE SC 4.6 and GNOME 2.28 
When the window is already mapped, we will use the same code and when it isn’t, we will call XChangeProperty. If KDE4 only promotes windows on top of its stack, the KDE team will have to fix it.
Error 503–Service Unavailable
It is not my fault. Thanks for reporting.
I use GNOME 2.32.1 at home, I have updated the test results here:
https://bugs.kde.org/show_bug.cgi?id=276159
Hi!
I have succeeded in building OpenJDK 1.6 and 1.7, the fix will be available soon ;D
Hi!
I have tried to use the same bug fix than in NEWT but in AWT and unfortunately, it does not work. I will have to investigate a bit deeper to fix this bug.
Hi
The bug seems to have several root causes :’(
There are some problems of bad use of XSync and the window handles might be obtained by the wrong way. NEWT uses the screen identifier and only a very little bit XQueryTree whereas AWT uses only XQueryTree in a loop to get the root window. Best regards.