Re: UTILITY, SPLASH, FULLSCREEN

["julian adams" <julian adams gmx net>]

I think it's important that the spec defines abstract things rather than
physical things - if that makes sense ! What I mean is we should be
labelling stuff as e.g. :

    splashscreen (abstract - what it is),

rather than

    stays-on-top+fullscreen (concrete-how it's done for one particular
implementation)

the former allows us to work at a much higher level, and (presumably) this
will be of help when considering accessability etc.


----- Original Message -----
From: "Havoc Pennington" <hp redhat com>
To: "Lubos Lunak" <l lunak sh cvut cz>
Cc: <wm-spec-list gnome org>; "Bradley T. Hughes" <bhughes trolltech com>;
"Matthias Ettrich" <ettrich kde org>
Sent: Thursday, October 18, 2001 3:20 PM
Subject: Re: UTILITY, SPLASH, FULLSCREEN


>
> 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
>
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>
>