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 <[email protected]
<mailto:[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:[email protected]>
<mailto:anthony.petrov@oracle.__com
<mailto:[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:[email protected]>
<mailto:anthony.petrov@oracle.__com
<mailto:[email protected]>>
<mailto:anthony.petrov@oracle.
<mailto:anthony.petrov@oracle.>____com
<mailto:anthony.petrov@oracle.__com
<mailto:[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]>__>__>
<mailto:[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]>__>__>
<mailto:[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:[email protected]>
<mailto:artem.ananiev@oracle.__com
<mailto:[email protected]>>
<mailto:artem.ananiev@oracle. <mailto:artem.ananiev@oracle.>____com
<mailto:artem.ananiev@oracle.__com
<mailto:[email protected]>>>
<mailto:artem.ananiev@oracle <mailto:artem.ananiev@oracle>.
<mailto:artem.ananiev@oracle
<mailto:artem.ananiev@oracle>.>______com
<mailto:artem.ananiev@oracle. <mailto:artem.ananiev@oracle.>____com
<mailto:artem.ananiev@oracle.__com
<mailto:[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
