Re: _NET: Disabling shading

[Lubos Lunak <l lunak suse cz>]

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).

>
> > 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.

>
> > 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.
 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.

>
> > If it isn't clear "modal-shadowed" means "windows that you can't
> > interact with while the modal window is alive"

-- 
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/