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 <[email protected]> > 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 <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 <[email protected] >> <mailto:anthony.petrov@oracle.**com <[email protected]>>> >> >> >> 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> >> >> >> <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 <[email protected] >> <mailto:anthony.petrov@oracle.**com<[email protected]> >> > >> <mailto:anthony.petrov@oracle.**__com >> >> <mailto:anthony.petrov@oracle.**com<[email protected]> >> >>> >> >> 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 <[email protected] >> <mailto:[email protected]**> >> <mailto:[email protected] >> <mailto:[email protected]**>__> >> <mailto:[email protected] >> <mailto:[email protected]**> >> <mailto:[email protected] >> <mailto:[email protected]**>__>__>> >> >> >> >> 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#__n8059<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#__n8059> >> <https://git.gnome.org/browse/** >> mutter/tree/src/core/window.c#**n8059<https://git.gnome.org/browse/mutter/tree/src/core/window.c#n8059> >> >> >> and >> 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> >> > >> >> <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 <[email protected] >> <mailto:[email protected]**> >> <mailto:[email protected] >> <mailto:[email protected]**>__> >> <mailto:[email protected] <mailto:[email protected] >> **> >> <mailto:[email protected] >> <mailto:[email protected]**>__>__>> >> >> >> >> 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> >> <http://hg.openjdk.java.net/__**jdk7/build/jdk/rev/__** >> ca34cfff70a4<http://hg.openjdk.java.net/__jdk7/build/jdk/rev/__ca34cfff70a4> >> > >> >> <http://hg.openjdk.java.net/__**jdk7/build/jdk/rev/__** >> ca34cfff70a4<http://hg.openjdk.java.net/__jdk7/build/jdk/rev/__ca34cfff70a4> >> <http://hg.openjdk.java.net/**jdk7/build/jdk/rev/** >> ca34cfff70a4 <http://hg.openjdk.java.net/jdk7/build/jdk/rev/ca34cfff70a4> >> >> >> >> Thanks, >> Vladimir >> >> >> >> 2013/4/16 Artem Ananiev <[email protected] >> <mailto:artem.ananiev@oracle.**com <[email protected]> >> > >> <mailto:artem.ananiev@oracle._**_com >> <mailto:artem.ananiev@oracle.**com <[email protected]> >> >> >> <mailto:artem.ananiev@oracle. >> <mailto:artem.ananiev@oracle.>**____com >> >> <mailto:artem.ananiev@oracle._**_com >> <mailto:artem.ananiev@oracle.**com <[email protected]> >> >>>> >> >> >> 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> >> >> >> >> <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> >> <http://bugs.sun.com/____**bugdatabase/view_bug.do?bug___** >> __id=7192269<http://bugs.sun.com/____bugdatabase/view_bug.do?bug_____id=7192269> >> > >> >> <http://bugs.sun.com/____**bugdatabase/view_bug.do?bug___** >> __id=7192269<http://bugs.sun.com/____bugdatabase/view_bug.do?bug_____id=7192269> >> <http://bugs.sun.com/__**bugdatabase/view_bug.do?bug___** >> id=7192269<http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=7192269> >> >> >> >> >> <http://bugs.sun.com/____**bugdatabase/view_bug.do?bug___** >> __id=7192269<http://bugs.sun.com/____bugdatabase/view_bug.do?bug_____id=7192269> >> <http://bugs.sun.com/__**bugdatabase/view_bug.do?bug___** >> id=7192269<http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=7192269> >> > >> <http://bugs.sun.com/__**bugdatabase/view_bug.do?bug___** >> id=7192269<http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=7192269> >> <http://bugs.sun.com/**bugdatabase/view_bug.do?bug_** >> id=7192269 <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7192269> >> >>> >> which marked >> as Not an Issue and for me is not clear why? >> >> Could you please suggest workaround? Or please >> fix this =) >> >> Best Regards, >> Vladimir >> >> >> >> >> >> >> >>
