Re: _NET: Disabling shading

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

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.

> 
> >
> > > My view is that this needs to fit in to a larger replacement plan for
> > > the MWM hints. The MWM hints currently cover disabling minimization,
> > > etc.
> > >
> > > My view on that replacement plan is that we should stick to the semantic
> > > window types, and deprecate all hints that explicitly control the window
> > > controls and other features. Modal dialogs should be implemented in
> > > toolkits by setting the MODAL hint and hints such as TRANSIENT_FOR
> > > indicating which windows are modal-shadowed, and that's it. The WM has
> > > to do the rest such as changing available controls and preventing focus
> > > of shadowed windows.
> >
> > I agree with that 100 percent.
> 
>  I agree too. I currently ignore most MWM hints in KWin, and those that are 
> not ignored are considered to be rather workarounds for non-EWMH apps. The 
> closing one is supported just become Motif programmers apparently don't know 
> how to have WM_DELETE_WINDOW, the resizing one is a workaround for lame 
> programmers not setting size constraints, and the moving one can be 
> considered a workaround for not specifying window type. Maximize and minimize 
> are completely ignored (maximizing is technically just resizing, and 
> minimizing is technically very similar to shading or not being on the active 
> desktop). Shading is about the same.
> 
>  BTW, the description in the rationale looks to me either like an application 
> modal dialog, which is something we already have, and IMHO it's up to the WM 
> whether to allow shading/minimizing/whatever of such windows, or it's desktop 
> global modal dialog, which probably none of the WMs here implements, and I'd 
> say also none of us would want to implement it.
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.

> 
> >
> > > We may well need to have a richer language for expressing which windows
> > > are modal shadowed though; at the very least, the spec needs to be more
> > > clear about how to determine which windows are unresponsive while a
> > > window of type MODAL is active.
> >
> > Wouldn't the window group hint be a good candidate?
> 
>  Yes. I think we even have it in the spec already, in the description of 
> _NET_WM_STATE_MODAL :). I don't think there is need for more grained 
> specification of which windows it makes modal that what's currently in the 
> spec, as applications usually don't have more complex their internal state of 
> modality.
There is a need for more grained specification, and applications usually
DO have more complex modality states in design, they just unable to
implement them. There are at least three kinds which people usually
request from Java - parent-wide, group-wide, application-wide. On
Windows, there is also system-wide. So there is at least four kinds
known. 

>  On the other hand, I wouldn't mind extending WM_TRANSIENT_FOR to be able to 
> point to more than one window, as I actually recently encountered a problem 
> related to this WM_TRANSIENT_FOR limitation. I'll try to write a patch for 
> the spec and post it.
I would really like to not extend WM_TRANSIENT_FOR anymore and to
introduce some special property related to this. WM_TRANSIENT_FOR has
been designed to serve other purposes.

Denis