(original) (raw)
Artem,
In this case I agreen with you, and your's changes is more small and should work as expected and touch only X11 area.
Perfect!
2013/4/18 Artem Ananiev <artem.ananiev@oracle.com>
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:
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.
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
<mailto:anthony.petrov@oracle.com>><mailto:vova.kravets@gmail.com <mailto:vova.kravets@gmail.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>https://git.gnome.org/browse/\_\_mutter/tree/src/core/window.c#\_\_n8059
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>
and
https://git.gnome.org/browse/\_\_mutter/tree/src/core/window.c#\_\_n8120<mailto:vova.kravets@gmail.com
<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>\_\_>>http://hg.openjdk.java.net/\_\_jdk7/build/jdk/rev/\_\_ca34cfff70a4
Heh... I see that Anthony made this changes 3 years ago =(<mailto:artem.ananiev@oracle.\_\_com
<http://hg.openjdk.java.net/jdk7/build/jdk/rev/ca34cfff70a4>
Thanks,
Vladimir
2013/4/16 Artem Ananiev <artem.ananiev@oracle.com
<mailto:artem.ananiev@oracle.com>https://github.com/vkravets/\_\_\_\_FullScreenTest
<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>Quote from GraphicsDevice#\_\_\_\_setFullScreenWindow:
<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:http://bugs.sun.com/\_\_\_\_bugdatabase/view\_bug.do?bug\_\_\_\_\_id=7192269
"
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>>
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