<AWT Dev> Modal dialogs for fullscreen window

Thu Apr 18 11:11:14 PDT 2013

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 at 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 at oracle.com
>>> <mailto:anthony.petrov at oracle.**com <anthony.petrov at 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 at gmail.com
>>> <mailto:vova.kravets at gmail.com**>
>>> <mailto:vova.kravets at gmail.com <mailto:vova.kravets at 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#**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>
>>> >
>>>
>>> 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 at gmail.com
>>> <mailto:vova.kravets at gmail.com**>
>>> <mailto:vova.kravets at gmail.com
>>> <mailto:vova.kravets at 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>
>>> <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 <artem.ananiev at oracle.com
>>> <mailto:artem.ananiev at oracle.**com <artem.ananiev at oracle.com>>
>>> <mailto:artem.ananiev at oracle._**_com
>>> <mailto:artem.ananiev at oracle.**com <artem.ananiev at 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>
>>> <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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20130418/d785eb92/attachment.html 