<AWT Dev> Modal dialogs for fullscreen window
vova.kravets at gmail.com
Tue Apr 16 08:48:56 PDT 2013
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
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
2013/4/16 Vladimir Kravets <vova.kravets at gmail.com>
> Heh... I see that Anthony made this changes 3 years ago =(
> 2013/4/16 Artem Ananiev <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?
>> 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:
>>> 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
>>> 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>which marked
>>> as Not an Issue and for me is not clear why?
>>> Could you please suggest workaround? Or please fix this =)
>>> Best Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the awt-dev