<AWT Dev> KDE Task bar is always on top of fullscreen Java applications

Anthony Petrov anthony.petrov at oracle.com
Fri Jul 1 05:03:05 PDT 2011

Hi Julien,

On 7/1/2011 1:06 AM, gouessej at orange.fr wrote:
> I have succeeded in compiling OpenJDK, I use Lesstif instead of openmotif because of the bug 1575 of Mageia Linux 1 (no openmotif packages). If I provide a Mercurial changeset, will someone be able to use my small contributions? Do I have to provide something else? Best regards.

Thanks you for you contribution!

But we need to review the fix first. Could you please generate a webrev 
[1] for you fix and publish it somewhere on the web? Or you could just 
attach a patch to an email message here on the mailing list.

Please note that after you OCA is approved, you'll get a valid OpenJDK 
ID. Then you'll be able to use the cr [2] web-site for publishing 
webrevs. Also, you'll be able to create changesets that can be 
integrated in an OpenJDK repository. Until then, someone else (e.g. me) 
should create a changeset and integrate it. Please note that the 
changeset will contain a correct "Contributed-by:" tag, so your name and 
email address will be associated with the changeset anyway.

On 7/1/2011 2:27 AM, gouessej at orange.fr wrote:
> I get this at the end of the compilation:
> "/usr/bin/ld: cannot open output file libjvm.so: Too many levels of symbolic links"
> I tried to recompile after cleaning all. What can I do to work around this problem?

Regarding this, and the lesstif issue. I think you're building some old 
repository. Could you please clone OpenJDK 8 jdk repo [3] and try it 
out? JDK8 (as well as 7) don't require any Motif libraries at all. Also, 
they should be easily buildable, and the process should take just some 
10 minutes.

[1] http://blogs.oracle.com/jcc/entry/webrev_for_openjdk_a_code

[2] http://cr.openjdk.java.net

[3] http://hg.openjdk.java.net/jdk8/awt/jdk/

best regards,

>> Message du 29/06/11 21:29
>> De : "Anthony Petrov" 
>> A : gouessej at orange.fr
>> Copie à : awt-dev at openjdk.java.net
>> Objet : Re:  KDE Task bar is always on top of fullscreen Java applications
>> On 6/29/2011 5:59 PM, gouessej at orange.fr wrote:
>>> How can I detect whether a window is mapped? When XQueryTree returns zero, does it mean that the window is unmapped?
>> You could use XGetWindowAttributes() and examine the map_state field of 
>> the XWindowAttributes() structure.
>> Alternatively, you could pass an additional argument to the 
>> X11GD_SetFullscreenMode() because at AWT level we always know whether a 
>> window is mapped (see XBaseWindow.isMapped()).
>> PS. Your email client seems to replace the correct mailing list address 
>> "awt-dev at openjdk.java.net" with something strange: 
>> "awt-dev at rea.oracle.com" when pressing Reply All. Could you please 
>> configure it properly?
>> --
>> best regards,
>> Anthony
>>> I can create another patch, I will do this as soon as possible. I will ask to the KDE team that it is up to them not to promote only windows on top of the stack.
>>>> Message du 29/06/11 15:17
>>>> De : "Anthony Petrov" 
>>>> A : gouessej at orange.fr
>>>> Copie à : awt-dev at rea.oracle.com
>>>> Objet : Re: KDE Task bar is always on top of fullscreen Java applications
>>>> Hi Julien,
>>>> So in your sample application you first set the window to the full 
>>>> screen mode, and only then you setVisible(true) it. In this case the 
>>>> EWMH spec states the following:
>>>> ***********************************************************
>>>> The Window Manager SHOULD honor _NET_WM_STATE whenever a withdrawn 
>>>> window requests to be mapped.
>>>> ***********************************************************
>>>> In other words, the X11GD_SetFullscreenMode() should actually check 
>>>> whether the window is currently mapped, and if so, do exactly what it 
>>>> currently does. However, if the window is currently unmapped, then we 
>>>> indeed have to use the XChangeProperty() call instead of the 
>>>> XSendEvent() one.
>>>> Please note that in either case we should not set the 
>>>> _NET_WM_STATE_ABOVE state. The _NET_WM_STATE_FULLSCREEN alone should 
>>>> work just fine. If it doesn't, then this is a problem with KDE.
>>>> Could you please try to create such a patch and test it on KDE4?
>>>> --
>>>> best regards,
>>>> Anthony
>>>> On 6/29/2011 3:49 PM, gouessej at orange.fr wrote:
>>>>> One guy of the KDE team answered that we have misunderstood the EWMH specification, that some window managers derivate from it and that using XChangeProperty there has some sense. What should I do now?
>>>>>> Message du 28/06/11 22:13
>>>>>> De : "Anthony Petrov" 
>>>>>> A : "Phil Race" 
>>>>> , gouessej at orange.fr
>>>>>> Copie à : awt-dev at openjdk.java.net
>>>>>> Objet : Re: KDE Task bar is always on top of fullscreen Java applications
>>>>>> Phil: Ah, right! Haven't used to the new rules yet. Thanks for reminding 
>>>>>> us about that.
>>>>>> Julien: I have a few questions about your patch:
>>>>>> 1. The xprop output that you've attached to the KDE bug report [1] 
>>>>>> indicates that the full screen window is maximized (i.e. using the 
>>>>>> emulated full screen mode rather than the exclusive one). In this case, 
>>>>>> the behavior is correct. But I assume you did try to do the same with 
>>>>>> the exclusive FS mode enabled, didn't you? Could you please provide an 
>>>>>> xprop output in that case, too?
>>>>>> 2. The EWMH specification [2] states that "A Client wishing to change 
>>>>>> the state of a window MUST send a _NET_WM_STATE client message to the 
>>>>>> root window". However, your proposed patch calls XChangeProperty() which 
>>>>>> changes the property manually, and therefore violates the EWMH spec. I 
>>>>>> think that a subsequent XSendEvent() to the root window should be enough 
>>>>>> for our purposes.
>>>>>> 3. The comments at the KDE bug report, as well as the EWMH spec (see the 
>>>>>> "Stacking order" section) suggest that a window with the 
>>>>>> _NET_WM_STATE_FULLSCREEN state should already be above any other windows 
>>>>>> (including the _NET_WM_STATE_ABOVE windows). Also, the specification 
>>>>>> states that the latter state should not be used by applications 
>>>>>> directly. Note that the function X11GD_SetFullscreenMode() which you're 
>>>>>> changing with your patch already sets the _NET_WM_STATE_FULLSCREEN state 
>>>>>> to the full screen window, and, according to the EWMH specification, 
>>>>>> that alone should work fine for full screen windows. So doesn't this 
>>>>>> then seem to be a bug in KDE4 actually?
>>>>>> [1] https://bugs.kde.org/show_bug.cgi?id=276159
>>>>>> [2] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>> On 6/28/2011 8:26 PM, Phil Race wrote:
>>>>>>> Anthony,
>>>>>>> That looks like a "small patch" so by the recent relaxation of the 
>>>>>>> rules an OCA isn't needed.
>>>>>>> -phil.
>>>>>>> On 6/28/2011 5:02 AM, Anthony Petrov wrote:
>>>>>>>> Hi Julien,
>>>>>>>> For your contribution to be acceptable, you have to sign an OCA. 
>>>>>>>> Please refer to this page for details on how to become an OpenJDK 
>>>>>>>> contributor:
>>>>>>>> http://openjdk.java.net/contribute/
>>>>>>>> -- 
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>> On 6/27/2011 4:03 PM, gouessej at orange.fr wrote:
>>>>>>>>> Hi!
>>>>>>>>> I think I have found a fix for this bug. On GNOME and on KDE the 
>>>>>>>>> atoms remain unchanged according to xprops but the X client message 
>>>>>>>>> is sent, that is why I call XChangeProperty. On the other hand, only 
>>>>>>>>> a window on top of the stack can become fullscreen, that is why I use 
>>>>>>>>> _NET_WM_STATE_ABOVE. I fear that building OpenJDK requires a lot of 
>>>>>>>>> time. Could someone with a ready environment make a build for me with 
>>>>>>>>> this fix? My "patch" is in the bug report here:
>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057287
>>>>>>>>> Best regards
>>>>>>>>> Julien Gouesse
>>>>>>>>>> Message du 23/06/11 14:50
>>>>>>>>>> De : "Anthony Petrov" A : gouessej at orange.fr
>>>>>>>>>> Copie à : Objet : Re: KDE Task bar is always on top of fullscreen 
>>>>>>>>>> Java applications
>>>>>>>>>> Hi,
>>>>>>>>>> On 06/22/2011 02:28 PM, gouessej at orange.fr wrote:
>>>>>>>>>>> Yes, that's it. I'm sad because I'm using JOGL AWT canvas called
>>>>>>>>>>> GLCanvas and this bug impacts my first person shooter. If I knew
>>>>>>>>>>> better the source code of AWT, I would try to write a patch. I assume
>>>>>>>>>>> there is a way of detecting the window manager to apply this fix only
>>>>>>>>>>> in this case, isn't it?
>>>>>>>>>> This window state is a part of EWMH specification, so there's no 
>>>>>>>>>> need to set it for specific WMs only.
>>>>>>>>>>> Does AWT currently rely on xrandr or VidMode on Linux? Best regards.
>>>>>>>>>> I think this question belongs to the 2d-dev at openjdk mailing list. 
>>>>>>>>>> I'm not a Java2D expert. Please ask 2D folks about that.
>>>>>>>>>> PS. Please remember to use Reply All rather than just Reply so that 
>>>>>>>>>> your message hits the mailing list.
>>>>>>>>>> -- 
>>>>>>>>>> best regards,
>>>>>>>>>> Anthony
>>>>>>>>>>>> Message du 22/06/11 12:11
>>>>>>>>>>>> De : "Anthony Petrov" A : gouessej at orange.fr
>>>>>>>>>>>> Copie à : awt-dev at openjdk.java.net
>>>>>>>>>>>> Objet : Re: KDE Task bar is always on top of fullscreen Java 
>>>>>>>>>>>> applications
>>>>>>>>>>>> Hello,
>>>>>>>>>>>> On 6/22/2011 1:14 PM, gouessej at orange.fr wrote:
>>>>>>>>>>>>> The exclusive fullscreen mode is broken in KDE for Java 
>>>>>>>>>>>>> applications as I explained here:
>>>>>>>>>>>>> https://bugs.kde.org/show_bug.cgi?id=276159
>>>>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057287
>>>>>>>>>>>>> (not yet visible)
>>>>>>>>>>>>> After some investigations, the problem comes from Java which does 
>>>>>>>>>>>>> not
>>>>>>>>>>>>> tag the window as fullscreen. Do you know how to fix this bug?
>>>>>>>>>>>> To tag full screen windows with the _NET_WM_STATE_FULLSCREEN 
>>>>>>>>>>>> state? That's easy. :)
>>>>>>>>>>>> Thanks for filing the bug report. AWT team will take care of this 
>>>>>>>>>>>> issue.
>>>>>>>>>>>> -- 
>>>>>>>>>>>> best regards,
>>>>>>>>>>>> Anthony

More information about the awt-dev mailing list