<AWT Dev> Fwd: Modal dialogs for fullscreen window

Vladimir Kravets vova.kravets at gmail.com
Tue Apr 16 03:00:38 PDT 2013

Sorry, to going to fullscreen mode using OpenGL in any case create "always
on top" _NET_WM_STATE_FULLSCREEN with OverrideRedirect and on it create
opengl surface...

But in any case is not logical behavior for me relative to QT, GTK, SWT


2013/4/16 Vladimir Kravets <vova.kravets at gmail.com>

> I'm talking for X11 implementation only... Since in this case to going to
> fullscreen you use native X11 _NET_WM_STATE_FULLSCREEN atom which mean is
> not exclusive fullscreen mode. In this case all WM which is use this mode
> can show any child modal dialogs above fullscreen window. As I said before
> this is a regression since on the Java 1.6 everything is working well with
> code with I mentioned above. For another OS's impelementation should be
> stays as is since it's using "real" exclusive fullscreen mode. (E.g. window
> - DirectX, Mac - owns binding to mac internal implementation).
> If you want to going to fullscreen exclusive mode on Linux I think need to
> used OpenGL api, not WM api. Because in this case it's not exclusive
> fullscreen mode, but in window manager fullscreen mode is able to switch
> between another windows and show application level windows above fullscreen
> window.
> BTW, Oracle NetBeens faced with the same issue with is not logical as for
> me... As I said before all WM and frameworks like (QT, GTK, SWT) on Linux
> support such behavior and it's logical because this is only application
> level (window manager) fullscreen mode, not exclusive.
> I think in this case need to support exclusive fullscreen which will be
> used (e.g. OpenGL) and non exclusive which will use above mentioned atom.
> BTW exclusive moden with _NET_WM_STATE_FULLSCREEN can be also doing by
> OverrideRedirect window type.
> In any case since this is a regression which made in 1.7 current behavior
> is not logical for me and as I know for alot of devs....
> Any suggestion about this?
> Thanks,
> Vladimir
> 2013/4/16 Anthony Petrov <anthony.petrov at oracle.com>
>> This issue cannot be fixed for all platforms. E.g. on MS Windows this is
>> technically impossible to display a regular top-level window in the
>> exclusive full screen mode. I suppose that the same limitation may apply to
>> the exclusive full screen mode on other platforms, too. So this just can't
>> be fixed.
>> Please note that you only need the exclusive full screen mode for high
>> performance rendering (e.g. for video games), in which case you most
>> probably don't want to display any top-level windows anyway since they are
>> going to look inconsistent with the rest of your UI. However, in the
>> emulated full screen mode the rendering performance may not be as good as
>> in the exclusive mode. Thus, depending on your particular needs you should
>> choose and use the right full screen mode for your application.
>> --
>> best regards,
>> Anthony
>> On 4/16/2013 13:15, Vladimir Kravets wrote:
>>> Hi Anthony,
>>> Thanks a lot for workaround, I will definitely try to use it... But, is
>>> this issue will be fixed?
>>> Thanks,
>>> Vladimir
>>> 2013/4/16 Anthony Petrov <anthony.petrov at oracle.com <mailto:
>>> anthony.petrov at oracle.**com <anthony.petrov at oracle.com>>>
>>>     Hi Vladimir,
>>>     A workaround is to not use the exclusive full screen mode, but
>>>     instead emulate it. Call Window.setAlwaysOnTop(true), and then
>>>     resize your window to occupy the whole screen area as reported by
>>>     GraphicsConfiguration. getBounds().
>>>     --
>>>     best regards,
>>>     Anthony
>>>     On 4/15/2013 20:56, 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
>>>         You can look at test application on the github:
>>>         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>
>>> >
>>>         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/20130416/b0ce5b62/attachment.html 

More information about the awt-dev mailing list