Re: _NET: Disabling shading

["Matthias Clasen" <maclas gmx de>]

> On Wed, 2003-10-01 at 13:32, Lubos Lunak wrote:
> > On Wednesday 01 of October 2003 09:45, Dominik Vogt wrote:
> > > On Tue, Sep 30, 2003 at 05:29:46PM -0400, Havoc Pennington wrote:
> > > > > On Tue, 2003-09-30 at 10:22, Denis O. Mikhalkin wrote:
> > > > > > Hi,
> > > > > >
> > > > > > we want to open the discussion regarding support for shading in
> > > > > > different WMs, in particular those implementing _NET protocol.
> > > > > >
> > > > > > Right now there is no means in _NET protocol to disable shading
> for
> > > > > > a window. There is no state of the window in which the WM would
> > > > > > consider shading for this window disabled. We propose to add a
> > > > > > special state to support disabled shading.
> > >
> > > I think we need a _NET_WM_ANNOY_USER_IN_MOST_DISRUPTING_WAY
> > > message too ;-)
> > 
> >  It's called urgency hint, and it's in the ICCCM :). Let's skip the fact
> that 
> > the only WM I know that supports it is FVWM, and it supports it by doing
> 
> > nothing by default IIRC (but I may be wrong here, it's a long time since
> I 
> > checked this).
> The way to notify the user about important background actions requiring
> attention has been asked from AWT for some time but we wern't able to
> provide the implementation since it is not widely supported. I really
> would like to see it a part of the _NET protocol - since, as being said,
> ugrency hint is not well supported, I think that the _NET equivalent
> will be more respected by implementors.

The urgency hint *is* part of the EWMH, see "Prerequisites for adoption of
this specification":

Window Managers and Clients which aim to fulfill this specification MUST
adhere to the ICCCM on which this specification builds. If this specification
explicitly modifies the ICCCM Window Managers and Clients MUST fulfill these
modifications. 

and "Urgency":

Windows expecting immediate user action should indicate this using the
urgency bit in the WM_HINTS.flags property, as defined in the ICCCM. 


It is unfortunate wm authors commonly choose to ignore certain aspects of
the ICCCM, but duplicating
these aspects as EWMH features is certainly not the right way to address
this.


> WM can't always make the decision whether to allow/disallow something
> based only on general information. There are some windows which
> developers like to keep non-focusable(toolbars for example), shouldn't
> be shaded(critical, blocking), should be minimized(critical, blocking).
> Probably, we can categorize such windows(criticial, blocking, popup) and
> allow the developer to specify into which category his windows falls and
> by this allow WM to decide how to interpret such a window. But until
> there is no such categorization, developers like to have the control
> over their windows. Another downside of allowing WM to control this is
> that WMs are different, and sometimes they interpret things differently,
> but developers like to see their programs behave similarly at least on
> some set of platforms.

This is the big misunderstanding. It's the users desktop and they should be
in
control of the windows appearing on it, with the help of a wm which they've
selected
for its interpretation of the specs.  

Matthias



-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++