<AWT Dev> Modal dialogs for fullscreen window
Anthony Petrov
anthony.petrov at oracle.com
Mon Apr 22 06:45:06 PDT 2013
Hi Vladimir,
Thanks for updating the fix. My only comment is about formatting:
usually we prefer lines with lengths no longer than 80 characters. Could
you please break the ?: operator to multiple lines? Otherwise it looks
good to me. I assume you have tested this fix and it works as expected
for your use cases?
Although I'm a little concerned about other window managers that may
present DIALOG windows somehow completely differently (as some Mac-style
sheets for example). In this case the fix may fail since it marks
regular owned windows as DIALOGs, too. This is purely a theoretical
concern, but still something to think about. Shouldn't we check the
window type instead of just checking whether the window has an owner or not?
--
best regards,
Anthony
On 04/20/13 15:17, Vladimir Kravets wrote:
> 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
> <mailto: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>
> <mailto:anthony.petrov at oracle.__com
> <mailto: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>
> <mailto:anthony.petrov at oracle.__com
> <mailto:anthony.petrov at oracle.com>>
> <mailto:anthony.petrov at oracle.
> <mailto:anthony.petrov at oracle.>____com
>
> <mailto:anthony.petrov at oracle.__com
> <mailto: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>__>__>
> <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
> <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>__>__>
> <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
> <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>
> <mailto:artem.ananiev at oracle.__com
> <mailto: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>>>
> <mailto:artem.ananiev at oracle <mailto:artem.ananiev at oracle>.
> <mailto:artem.ananiev at oracle
> <mailto: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>>>>>
>
>
> 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
>
>
>
>
>
>
>
>
More information about the awt-dev
mailing list