Re: _NET: Disabling shading

[Lubos Lunak <l lunak suse cz>]

On Wednesday 01 of October 2003 12:24, Denis O. Mikhalkin wrote:
> On Wed, 2003-10-01 at 13:32, Lubos Lunak wrote:
[snip]
> 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.

 I think Matthias Clasen's comment says it all. And for your specific 
examples, we already have it. The WM may decide to restrict focusing of 
TYPE_TOOLBAR windows. Windows critical/blocking/popup are with urgency hint, 
with STATE_MODAL, without STATE_MODAL.
 If we start having flags controlling every basic property of windows, instead 
of specifying what a specific window is, we greatly restrict WM's abilities 
to affect what's going on (since it in fact will know nothing useful about 
the window), and we also restrict future extensibility (guess why it's not 
possible to forbid e.g. shading with MWM hints, while with EWMH the decision 
can be just "these kinds/states of windows yes, the rest no").

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

 Aha, I have never seen this myself. Is there some document or application 
which I could have a look at to see the difference?

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

 As far as I know, WM_TRANSIENT_FOR is usually understood as "this is my 
main/superior window". In which case wouldn't this be good enough for modal 
dialogs?

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