Re: WHY: Re: Still need a hint for undecorated windows
- From: Lubos Lunak <l lunak suse cz>
- To: wm-spec-list gnome org
- Subject: Re: WHY: Re: Still need a hint for undecorated windows
- Date: Fri, 24 Jun 2005 14:19:13 +0200
On Friday 24 of June 2005 13:30, Bill Haneman wrote:
> Tuomo Valkonen wrote:
> > On 2005-06-24, Carsten Haitzler <raster rasterman com> wrote:
> >>On Fri, 24 Jun 2005 11:54:54 +0200 Lubos Lunak <l lunak suse cz> babbled:
> >>> I yet to have actually see somebody saying a single reason why this is
> >>> really
> >>
> >>application developers want it
> >
> > Because they mistakenly think they know better than the user or the wm
> > maker how UIs should work, not because they have any real reason for it.
> > This kind of thinking only eventually leads to the loss of such a
> > blessing as a separate window manager, and thus to absolute unusability.
>
> Ridiculous.
>
> Here's a GOOD REASON for this hint:
>
> * applications sometimes want/need to post windows that should not be
> decorated, and perhaps shouldn't even be distinguished visually as
> "separate top level windows" - examples are certain types of popups,
> splash screens, and transient windows.
_NET_WM_WINDOW_TYPE_SPLASH. No idea what exactly you mean with popups and
transient windows in this case.
>
> The usual way to deal with this problem is to either use WM_TYPE_DOCK,
> which is semantically inaccurate,
This may be the usual, but, as you point out yourself, incorrect way.
> or (more commonly) to use
> override-redirect. The problem with override-redirect is that it
> 'hides' the window from the WM, thus conflicting with assistive
> technologies such as onscreen magnifiers, onscreen keyboards, and
> defeating other WM functions.
>
> I agree that the WM is a "blessing", e.g. a Good Thing. It does lots of
> things for us _besides_ just adding decorations and drag handles. Why
> should we have to defeat all of the positive functionality of a WM in
> order to get undecorated windows (or else abuse WM_DOCK) ?
>
> You may think that splash screens are evil, that popups should never be
> toplevels, yadda yadda, but this hardly matters. Although the WM spec
> *should* set some degree of policy and encourage "good UI design", it is
> really hopeless to think that wm-spec-list is an appropriate universal
> arbitrator of what is good and bad. I don't think we can reach
> consensus that all forms of undecorated window (in an
> otherwise-decorated DE) are forever evil; therefore an UNDECORATED hint
> is required (until such time as all applications which disagree with you
> die out).
>
> The accessibility issue is a strong practical reason (as opposed to just
> a philosophical one) why the hint is better than just requiring such
> apps to use override-redirect or DOCK.
At least your conclusions are flawed. You basically argue that since current
hacks and workarounds don't quite work, we need better hacks and workarounds.
The proper way of handling splash screen is the window type, which we've
already had since some time. I don't know what you mean with the other
windows, but if e.g. onscreen keyboards/magnifiers are too different they can
get their own WM type as well that could also imply no border if needed
(although I don't quite see why - I use KMag normally with borders - I'm not
accessibility user though). I still don't see why we should encourage
"random" noborder windows just for the fun of it. And if we officially add a
hint to the spec it will encourage it and we'll see more xmms-like apps.
BTW, for those of you who don't know, Tuomo is a(the?) developer of the Ion
window manager. Given how Ion is different from our "traditional" WMs he's
probably seen more abuse from the apps then we all together.
--
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]