<AWT Dev> Modal dialogs for fullscreen window
Vladimir Kravets
vova.kravets at gmail.com
Sat Apr 20 04:17:03 PDT 2013
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 at 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 <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 at oracle.com
>> <mailto:anthony.petrov at oracle.**com <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>
>>
>> <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>
>> >
>> <mailto: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**>__>
>> <mailto: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>
>> >
>>
>> <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 <vova.kravets at gmail.com
>> <mailto:vova.kravets at gmail.com**>
>> <mailto:vova.kravets at gmail.com
>> <mailto:vova.kravets at gmail.com**>__>
>> <mailto: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>
>> >
>>
>> <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>
>> >>
>> <mailto:artem.ananiev at oracle.
>> <mailto: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>
>> >>
>> <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
>>
>>
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20130420/65e51761/attachment.html
More information about the awt-dev
mailing list