Re: small patch, for UTILITY/SPLASH types, and FULLSCREEN state

[Bj|rn Englund <d4bjorn dtek chalmers se>]

On 11 Oct 2001, Havoc Pennington wrote:

> 
> 
> I thought about that a bit - I think it implies that the window should
> be mapped on top, but I'm not sure it implies a constraint that the
> window is always on top - shouldn't you be able to Alt+Tab out of the
> fullscreen window? Can't you do this with PowerPoint presentations for
> example? And if there are two fullscreen windows can't you use Alt+Tab
> to go between them?

No it should not always be on top.

> 
> Perhaps we should specify that the window must be raised on transition
> to FULLSCREEN state? It may not be necessary to spec that though,
> maybe it's just a quality of implementation issue that depends on how
> a WM works.
Well I think it should be specified. Otherwise it won't get implemented
that way ;) At least spec it as '_should_ raise' if not _must_


If one changes the state of a window to fullscreen it _should_ be
raised to the top. Of course other windows like popup menus/dialogs/..
should be able to be above and if you decide so, you should be able
to lower the fullscreen window. But the main point of specifying
it to be raised is so that it will get above panels and other
windows that are usually 'on top'.
Only way now (using window type/state) is to make the window
a 'dock type' or similar. 

A wm that doesn't give you any option what to do with a fullscreen state
window should/must? raise it when entering fullscreen state.
Others may be configurable to always let the panel be on top...

When leaving the fullscreen state, the wm should
move the window to the position/"layer" it had before.


/Björn