Re: UTILITY, SPLASH, FULLSCREEN

[Havoc Pennington <hp redhat com>]

Lubos Lunak <l lunak sh cvut cz> writes: 
>  Is it really necessary to have something so special like flags for 
> splashscreens and fulscreen windows? I mean, what makes these two so special 
> that they deserve their own flags?

Basically, these (and UTILITY) are the only window types that I've
encountered which aren't handled by the existing hints. Since semantic
information lets the WM be really smart about the window, it's nice to
have it there. For example, as previously discussed, fullscreen
windows really require some smarts about how Alt+Tab is done, allowing
their transients on top, etc. - a "STAYSONTOP" hint doesn't give as
much info. A splashscreen is also stays on top, but should not be in
the tab list, and should be centered, and should be always underneath
FULLSCREEN. Also, for example, the WM might handle these differently
in a multihead or Xinerama context.  Another example - STAYSONTOP for
a splash screen may or may not be above the panel - I don't know - my
feeling is that a splash screen should probably be "mapped on top,
stays on top of window group, so you can keep working with other apps"
- but fullscreen is definitely on top of the panel.

> Splashscreen is just a window without 
> decorations centered on the desktop above all other windows, and fullscreen 
> is a window without decorations large as the desktop above all other
> windows.

As I said, I think the WM can do a nicer UI if it has more info than
this. There are lots of small tweaks you can do that are really nice,
and add cross-application consistency.

>  I don't know why neither Matthias Ettrich nor Bradley T. Hughes
> said anything, they are probably busy with Qt3.0 final. KDE already
> has NET_WM extensions that allow both splashscreens and fullscreen
> windows using more generic flags (which is IMHO a better
> solution). The two flags are NET_WM_STATE_STAYS_ON_TOP (it's not
> even marked as KDE extension in the docs, but I can't find it in the
> wm-spec) and _KDE_NET_WM_WINDOW_TYPE_OVERRIDE. The first one is
> obvious, and some users set this flags e.g. on ICQ window. The
> override flag is almost like using override_redirect, i.e. no
> decorations, but it has the benefit of e.g. staying only on the
> given desktop.

These are both "escape hatches" - ideally I'd like to see 99% of apps
be able to get away without them, using purely the intelligence of the
window manager. The resulting UI is more consistent and smooth, and
the window handling is smarter. Or at least can be smarter.

I do think we'll need escape hatches in the end, but I'd like to see
them provided just for "weird apps," not for standard/typical features
like splash screens.

If it looked like there were 24 more window types we're ignoring, my
opinion would be different, but UTILITY/SPLASH/FULLSCREEN seems to
cover the interesting missing cases. Maybe I just need to think
harder. ;-) UTILITY in particular is really broken right now though,
the various dialogs in the GIMP just are not dialogs in the usual
dialog sense, but they do need special handling. Mac OS Classic has
this concept of "utility windows" distinct from dialogs and main app
windows.

Havoc