Re: _NET: Disabling shading

["Denis O. Mikhalkin" <dom sparc spb su>]

On Wed, 2003-10-01 at 14:51, Matthias Clasen wrote:
> > 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.
I don't know why do they ignore it, but I suspect it might be because it
is old specification and thus there are some behaviours associated with
it which they don't like. So there are even more reasons to renew the
specification and explicitly declare a way(and necessity) to handle some
means of ugrency indication.

> 
> 
> > 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.  
I don't agree with that. I don't think user want to do what you say -
users usually want PREDICTABILITY. And I don't mean those rare Linux
gurus which happened to work on X, but those millions of desktop users
which we want to attract to Unix Desktops. They want the software they
have to work. They become very confused when something that worked
before starts to work differently, they want it to work as specified in
manuals and as it worked for some time. I doubt there are many of them
who know how to even change their desktop(Gnome or KDE), even less of
them know that WM exists and that it can be changed and know how to do
it. 

And it is obviosly that Unix desktop is already moving toward such users
- we hardcoded WM into desktop(Metacity-Gnome, KDE-KWin), it is now have
less options and is more tightly bound to other components. Here we come
to another predictability - that which developers expect. That's why we
standardize WM or other IPC interfaces, I am sure without them you can't
expect all those desktop-managing programs to work together so well. 

I think that the role of WM has changed - from managing component it
became more of a serving component. And being so it means that is should
provide more services, more control for correctness of them and less
decision making functions. Not surprisingly, developers which develop
software for desktops also like their software to work predictable and
to not confuse users by strange behaviors. They also would like to have
flexible environment - otherwise they might not be able to implement
feature-rich programs.

Remember that predictability and seemingless of program interfaces is
what made Windows win desktops. 

And to achieve predictability you should first specify interface, you
should eliminate all implicits("If you don't specify <something> then WM
is free to <decide something>" - this is wrong) and turn them into
explicit rules. It doesn't mean restriction - add as more explicit
features as you like. Add guidelines for what you think is a good UI in
terms of feature usage("toplevel are usually focusable, with caption..."
and so) so that developers don't misbehave. But you must not decide for
developers or users. If you do this - people will just switch to another
WM(or desktop). Note that feature richness doesn't result in
unpredictability when applied to variety of programs using features
differently. Every single program will behave predictable, and most of
them will operate with concepts known to user. If one wants to do
differently - it is his right.

Denis