<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
frameworks...
Thanks,
Vladimir
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
>>> _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>>.
>>> 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