[osg-submissions] fullscreen and windowed on gnome desktop

Cedric Pinson mornifle at plopbyte.net
Mon Oct 8 05:38:55 PDT 2007



Leif Delgass wrote:
> I've tested the Motif hint for removing decorations and yes it works
> fine under GNOME/metacity (metacity version is 2.14.3).  However, to
> get a top-level window above the panels for fullscreen, you need the
> fullscreen EWMH hint (which changes the window size, stacking, and
> decorations).    When setting the fullscreen state, turning off
> decorations with the Motif hint is redundant, but doesn't hurt.  To
> turn decorations on and off for a non-fullscreen window, the Motif
> hint is still necessary.
>   
Yes i have same behaviour here too with metacity 2.18.5
> Toggling fullscreen/windowed was failing without the fullscreen hint
> because the resize request is overriden by metacity and the
> "fullscreen" window ends up smaller than the screen, which in turn
> confuses the WindowSizeHandler.  Perhaps it would be more robust to
> keep an internal flag indicating the current (requested) fullscreen
> state rather than examining the window dimensions for the purpose of
> toggling fullscreen?
>   
In my opinion it's better to manage fullscreen as a different 'mode'. 
and add
function virtual function in the GraphicWindow and save the flag in the 
Trait.
I re enabled the MOTIF hint to have the same functionnality as before 
because
i believed it was a problem, but as you said it works.
> It also may be better to have the window size traits and GL context
> updated with the actual dimensions from the ConfigureNotify event.
> Since the GraphicsWindow's setWindowRectangle() calls resized(), this
> would probably mean blocking until the event is received in the
> setWindowRectangleImplementation.  I'm not sure if this would need a
> timeout though -- it may be possible that no event will come back if
> the window manager refuses the request.  If the resized() call was
> moved to the platform-specific implementations, then I think the X11
> implementation could just let checkEvents() handle the ConfigureNotify
> so it wouldn't have to block or assume a request will succeed in
> setWindowRectangleImplementation.  I'm not sure if there would be side
> effects to making setWindowRectangle asynchronous in this way though.
> Regarding the sleep:  I tried taking out the sleep and so far the only
> X error I've seen was on XSetInputFocus() which failed with a BadMatch
> error because the window wasn't visible at the time of the call (could
> be because the window was not mapped or was obscured).
>   
You mean the robust way to do that is to do things when we received 
event from X
right ?
> Also, one thing I haven't tested yet with the fullscreen hint: what
> happens in a Xinerama or merged framebuffer (TwinView) setup?  I think
> some window managers may try to maximize windows to the physical
> display rather than over the full desktop in that case.
>   
I can't test that too.
> Anyway, I hope this helps and doesn't confuse things too much more. ;)
>  Unfortunately, I have some work deadlines that prevent me from diving
> into the details right now, but I'll try to help out as time permits.
>
>   
Thank you for your report, i put a new patch as attachement. I will rework
on it later

> Leif
>
> On 10/6/07, Robert Osfield <robert.osfield at gmail.com> wrote:
>   
>> HI Leif,
>>
>> I'm curious about you comments.  Is it your belief that MotifHints
>> should work fine under Gnome?  Is it just the internal response to the
>> resize that you believe is the issue?   Removing the usleep() and
>> relying on the configure event sounds plausible solution.
>>
>> Robert.
>>
>> On 10/4/07, Leif Delgass <ldelgass at gmail.com> wrote:
>>     
>>> On 10/4/07, Cedric Pinson <mornifle at plopbyte.net> wrote:
>>>       
>>>> Hi
>>>> It's a patch to have fullscreen toggle working on gnome, it concerns
>>>> only X11 implementation.
>>>> the problem:
>>>> when i run osgviewer i can't go in windowed mode. When i want to go in
>>>> windowed mode the screen flash i see the viewport (only the gl viewport
>>>> not the window) to have the size of the window size asked by osg and the
>>>> frame after. It fails and rest in fullscreen. After some test i saw that
>>>> the problem was the MOTIF decoration setup. Metacity seems to not handle
>>>> correctly the window if there is no decoration.
>>>>
>>>> answer:
>>>> The idea is to not use the MOTIF decoration setup, and to send an ICCM
>>>> fullscreen event when it's appropriate. It means if the window has the
>>>> size of the screen and the decoration wanted is false then we send the
>>>> fullscreen event, else we send the event to disable the fullscreen mode.
>>>> The problem of this method is you can't have a window in a windowed
>>>> mode  without decoration. It's not a perfect solution.
>>>>
>>>> I tested it with compositviewer and osgviewer and it works great. I know
>>>> that most of WM now use ICCM features so i hope it will not be a problem
>>>> on other WM. Some feedback will be appreciate on others windows manager.
>>>>
>>>> Thanks to ldelgass at gmail.com for the piece of code.
>>>>
>>>>
>>>> Cheers
>>>>
>>>>
>>>> --
>>>> +33 (0) 6 63 20 03 56  Cedric Pinson mailto:mornifle at plopbyte.net http://www.plopbyte.net
>>>>         
>>> Hi Cedric,
>>>
>>> I have some comments on the changes:  I don't believe the motif hints
>>> are the problem per se, but your original comment about the
>>> isFullScreen test in ViewerEventHandlers is correct.  The motif
>>> decoration hints actually do work for me with GNOME/metacity, and can
>>> be used to get a non-fullscreen, undecorated window.  The problem is
>>> that when you remove decorations and attempt to resize the window to
>>> fullscreen without using the fullscreen hint, metacity makes the
>>> window smaller than screen size to account for the panels.  The
>>> toggleFullscreen in ViewerEventHandlers then fails to recognize that
>>> the window is "fullscreen" since the window manager modified the
>>> requested window size, so toggleFullscreen tries to make the window
>>> fullscreen on every toggle.
>>>
>>> The behavior you saw with the GL viewport not matching the window size
>>> is probably a consequence of the way resizing is implemented in
>>> GraphicsWindowX11.  The setWindowRectangleImplementation assumes it
>>> will get the requested size and adds a usleep to wait for the window
>>> manager.  I think this is a hack around the asynchronous nature of
>>> Xlib.  Really, the resize should not be assumed to work and should not
>>> be acted on (resizing the GL context) until a ConfigureNotify event is
>>> received with the actual new size of the window.  The window manager
>>> can refuse the resize altogether or it can resize to a different size
>>> than was requested.
>>>
>>> --
>>> Leif Delgass
>>> ldelgass at gmail.com
>>> _______________________________________________
>>> osg-submissions mailing list
>>> osg-submissions at lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>>
>>>       
>> _______________________________________________
>> osg-submissions mailing list
>> osg-submissions at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>
>>     
> _______________________________________________
> osg-submissions mailing list
> osg-submissions at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>   

-- 
+33 (0) 6 63 20 03 56  Cedric Pinson mailto:mornifle at plopbyte.net http://www.plopbyte.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: GraphicsWindowX11.cpp
Type: text/x-c++src
Size: 47784 bytes
Desc: not available
Url : http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/attachments/20071008/5ceaaf70/attachment-0001.cpp 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: GraphicsWindowX11
Url: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/attachments/20071008/5ceaaf70/attachment-0001.asc 


More information about the osg-submissions mailing list