http://bugs.sun.com/view_bug.do?bug_id=8012586 (should become available in a day or two). Please note that you don't need to commit any changes with mercurial. You can generate a webrev just for the files that are modified (webrev can identify them).
">

(original) (raw)

Hi Athony and Artem,

Done.
- Create fix based on AWT repository for JDK8.
- Upload to github pages.

Please look at review http://vkravets.github.io/awt-fixes/8012586/webrev.00/index.html

Best Regrads,
Vladimir


2013/4/18 Anthony Petrov <anthony.petrov@oracle.com>
Hi Vladimir,

Certainly. However, a fix must be pushed to the main development release first (which is JDK 8 currently) and tested properly (for at least a few weeks). Only then is it possible to back-port the fix to a 7 update release.

BTW, I've filed a bug for you: http://bugs.sun.com/view\_bug.do?bug\_id=8012586 (should become available in a day or two). Please note that you don't need to commit any changes with mercurial. You can generate a webrev just for the files that are modified (webrev can identify them).

\--
best regards,
Anthony


On 04/18/2013 10:11 PM, Vladimir Kravets wrote:
Anthony,

I working with 1.7 since I'm waiting such fix in 1.7 also.
Is it possible to see this fix in 1.7 next update?

Thanks,
Vladimir


2013/4/18 Anthony Petrov <anthony.petrov@oracle.com
<mailto:anthony.petrov@oracle.com>>


I agree with Artem. The fix should only touch the XAWT code.

Also, I've noticed you're using some very old repository. Please
clone the current jdk8 AWT development forest at:

http://hg.openjdk.java.net/\_\_jdk8/awt

<http://hg.openjdk.java.net/jdk8/awt>

Another suggestion is to not reformat any existing import statements
(or do any reformatting at all) unless necessary.

To generate a webrev just run the script in the jdk/ directory of
your repository. It will generate it in the jdk/webrev/. Then you
need to publish this webrev directory somewhere on the web and send
us a link to it.

\--
best regards,
Anthony


On 04/18/13 17:16, Artem Ananiev wrote:


On 4/18/2013 1:01 PM, Vladimir Kravets wrote:

Hi Anthony,

You can look on the attached patch.
Sorry but I cant figure out how I can do this with
webrev.ksh... Since I
performed checkout without forest extension... And really
don't know
what I should do to generate normal code review... I'm not
good familiar
with Mercurial... =(

Let me know if you are need something from my side also...

Patch was tested on Ubuntu 12.10 with tested application which I
mentioned before and also with "always on top" application.
Java 1.7
without patch - issue reproducible, with patch - issue is NOT
reproducible.


java.awt.Window is a public class, so we can't change its API in
minor
JDK releases. Moreover, I don't see a need in new Type.DIALOG,
it can be
fixed in XAWT code only:

diff -r 8fbe247ad2d8
src/solaris/classes/sun/awt/\_\_X11/XWindowPeer.java
\--- a/src/solaris/classes/sun/awt/\_\_X11/XWindowPeer.java Wed

Apr 17
11:24:40 2013 -0700
+++ b/src/solaris/classes/sun/awt/\_\_X11/XWindowPeer.java Thu

Apr 18
17:13:39 2013 +0400
@@ -1887,7 +1887,9 @@
switch (getWindowType())
{
case NORMAL:
\- typeAtom = protocol.XA\_NET\_WM\_WINDOW\_\_\_TYPE\_NORMAL;

\+ typeAtom = (ownerPeer == null) ?
\+ protocol.XA\_NET\_WM\_WINDOW\_\_\_TYPE\_NORMAL :
\+ protocol.XA\_NET\_WM\_WINDOW\_\_\_TYPE\_DIALOG;
break;
case UTILITY:
typeAtom = protocol.XA\_NET\_WM\_WINDOW\_\_\_TYPE\_UTILITY;



Thanks,

Artem

Thanks,
Vladimir


2013/4/17 Anthony Petrov <anthony.petrov@oracle.com
<mailto:anthony.petrov@oracle.com>
<mailto:anthony.petrov@oracle.\_\_com

<mailto:anthony.petrov@oracle.com>>>

Hi Vladimir,

Thanks for your investigations. Setting the
\_NET\_WM\_WINDOW\_TYPE\_DIALOG type for dialog windows looks
reasonable
to me.

Do you want to make a patch, test it, and post it here for
review?
Since you're on a \*NIX system, building OpenJDK shouldn't be a
problem at all. Just \`bash ./configure && make\`. The ./configure
script will tell you about all the required packages that
need to be
installed.

\--
best regards,
Anthony


On 04/16/2013 08:03 PM, Vladimir Kravets wrote:

Guys we have the real problem....And appears it not related to
fullscreen window =)
If window.alwaysOnTop(true) all dialogs in Metacity and its
clones will
be shown under the main window..... =(

Thanks,
Vladimir


2013/4/16 Vladimir Kravets <vova.kravets@gmail.com
<mailto:vova.kravets@gmail.com>
<mailto:vova.kravets@gmail.com
<mailto:vova.kravets@gmail.com>\_\_>
<mailto:vova.kravets@gmail.com
<mailto:vova.kravets@gmail.com>
<mailto:vova.kravets@gmail.com
<mailto:vova.kravets@gmail.com>\_\_>\_\_>>



I look at the mutter source and found that for dialog or
for window
which have WM\_TRANSIENT\_FOR should set type
\_NET\_WM\_WINDOW\_TYPE\_DIALOG.

If you look at
https://git.gnome.org/browse/\_\_\_\_mutter/tree/src/core/window.\_\_c#\_\_n8059
<https://git.gnome.org/browse/\_\_mutter/tree/src/core/window.c#\_\_n8059>
https://git.gnome.org/browse/____mutter/tree/src/core/window.__c#__n8120

<https://git.gnome.org/browse/__mutter/tree/src/core/window.c#__n8120>

<https://git.gnome.org/browse/__mutter/tree/src/core/window.c#__n8120

<https://git.gnome.org/browse/mutter/tree/src/core/window.c#n8120>>



At the fist step will check _NET_WM_WINDOW_TYPE if this set

it will

set the window type according to this type and

WM_TRANSIENT_FOR will

not check in this case. If _NET_WM_WINDOW_TYPE is not set and

WM_TRANSIENT_FOR is set the mutter will set to this window the

_NET_WM_WINDOW_TYPE_DIALOG window type. Thus

_NET_WM_WINDOW_TYPE

have more priority then WM_TRANSIENT_FOR...



Thus since AWT even for dialogs set

_NET_WM_WINDOW_TYPE_NORMAL (AWT

sets this always!!!!) we have incorrect behavior of modal

dialogs in

mutter and posible in another WM which using the same behavior.



Please fix this, since it's regression from 1.7 and this

problem

touch even Gnome3!





2013/4/16 Vladimir Kravets <vova.kravets@gmail.com

<mailto:vova.kravets@gmail.com>

<mailto:vova.kravets@gmail.com

<mailto:vova.kravets@gmail.com>__>


<mailto:vova.kravets@gmail.com>__>__>>






Heh... I see that Anthony made this changes 3 years ago =(

http://hg.openjdk.java.net/____jdk7/build/jdk/rev/____ca34cfff70a4

<http://hg.openjdk.java.net/__jdk7/build/jdk/rev/__ca34cfff70a4>
<mailto:artem.ananiev@oracle.

<mailto:artem.ananiev@oracle.>____com


<mailto:artem.ananiev@oracle.__com

<mailto:artem.ananiev@oracle.com>>>>





Hi, Vladimir,



I took a short look at your test at github. The test

implements its own mechanism to enter fullscreen by

adding

_NET_WM_STATE_FULLSCREEN to the list of atoms in

_NET_WM_STATE. There may be a conflict between

XToolkit and

the test, for example, caused by using different

Display

objects.



In XToolkit, _NET_WM_STATE_FULLSCREEN is only used in

exclusive fullscreen mode, see the code in

X11GraphicsDevice. I can't say for sure if OpenGL

is used in

this case. As for owned windows, nothing special is

done

about them. If a window has an owner,

WM_TRANSIENT_FOR is

set for it, which should be respected by WM. As you

say that

WM_TRANSIENT_FOR works fine together with

_NET_WM_STATE_FULLSCREEN in most of the modern WMs, it

should work for Java windows as well.



Could you check all the window properties both for the

fullscreen window and for the child windows, in your

environment, please? Are there any chances some of the

properties (_NET_WM_STATE, WM_TRANSIENT_FOR) are

not set for

some reason?



Thanks,



Artem





On 4/15/2013 8:56 PM, Vladimir Kravets wrote:



Hi guys,



I'm using in my application fullscreen mode.

Since 1.6

java have a lot

of issue with it I using X11 native binding for it.

Use JNA 3.4. To going to fullscreen I send

XSendEvent as

_NET_WM_STATE

with _NET_WM_STATE_FULLSCREEN



You can look at test application on the github:

https://github.com/vkravets/______FullScreenTest

<https://github.com/vkravets/____FullScreenTest>


<https://github.com/vkravets/____FullScreenTest

<https://github.com/vkravets/__FullScreenTest>>

<https://github.com/vkravets/____FullScreenTest

<https://github.com/vkravets/__FullScreenTest>

<https://github.com/vkravets/__FullScreenTest

<https://github.com/vkravets/FullScreenTest>>>. Main



Class: Main or MinTest



So about the issue... I have an issue with

modal dialogs

or windows

which I try to show when my main window in

fullscreen mode.

From 1.7 java is not working as expected. In

1.6 java

modal

dialogs/windows appeared above fullscreen

window as it

should be, but in

1.7 and 1.8 all modal dialogs/windows appeared

under the

fullscreen window.



I'm using wm Metacity, the same I have noticed

on Gnome

Shell... It

seems that it's related to all clones of

Metacity...



I'm try to see how it's perform by defult native

frameworks and I tested

GTK3 and SWT which is using GTK bindings. And

everything

is working as

expected. SmartGit which written on Java and

use SWT

don't have such

problem. VLC/GTK the same - in fullscreen mode

I can

call some dialogs

which will be appeared above fullscreen window.



It's very strange for me that Java in own

documentation

have such lines:

Quote from GraphicsDevice#______setFullScreenWindow:




"

Windows cannot overlap the full-screen window.

All other

application

windows will always appear beneath the full-screen

window in the Z-order.

"



Since from 1.7 java is using the same message

_NET_WM_STATE with

_NET_WM_STATE_FULLSCREEN to going to fullscreeb

and is

not clear why we

have such broken behavior with modal dialogs

from 1.7

java and such

lines in the documentation....



I'm already posted a defect to Oracle but

Ithink it will

be marked as

duplicate since I found such issue

http://bugs.sun.com/______bugdatabase/view_bug.do?bug_______id=7192269

<http://bugs.sun.com/____bugdatabase/view_bug.do?bug_____id=7192269>