Re: New Fullscreen Window Method



Am 06.02.2012 12:45, schrieb Lubos Lunak:
> On Friday 03 of February 2012, Karl F. Glatzer wrote:
>> I must admit that you are right about thinking that only the WM and
>> Configuration Utilities should change the desktop resolution or similar
>> changes.
> 
>  That's right. In fact, applications should never change desktop geometry at 
> all. At most, they might want to resize the viewport.

I think they shouldn't even need to resize the viewport themselves. The
idea of this is to tell the WM where and with which resolution the
window should be displayed. Then the WM can decide how this is
accomplished and send the application a notification that the request
was handled successfully or that it failed.

>  If you do not know what the difference is, then desktop geometry is what the 
> applications see, while the viewport is the monitor resolution.
> 
>  Currently SDL resizes the desktop, which usually leads the WM to resize all 
> windows to fit in the new size, panels are moved, etc. . If the size is 
> something small, this usually ruins the setup, because going to something as 
> small as e.g. 640x480 is a resize operation that most applications cannot 
> revert to original.
> 
>  As such, I suggest you do not use the word "fullscreen" for this, as it is 
> overloading the word with another meaning for a different concept. What you 
> want is a window to be, uhm, "viewported".

I think fullscreen is the right term for this as this is about
applications being able to create windows which cover the whole screen
without being bound to the current desktop/screen resolution. If this is
accomplished via changing the viewport, resizing the desktop or with
scaling as suggested here:

http://lists.libsdl.org/pipermail/sdl-libsdl.org/2012-February/083700.html

should be the decision of the WM and shouldn't matter for the spec apart
from deciding which informations the WM and the application need to
receive from each other to work properly independent of the method the
WM uses.

What can be done is suggesting which methods should have higher priority
for implementing and also suggesting the WM developers to let the user
configure which method the WM should use.

>  As for the actual implementation, I assume it might be sufficient to have 
> another WM_STATE flag that will cause the viewport to be set to the window's 
> geometry (or as closely as possible) whenever that window is the active one.
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]