Re: _NET: Disabling shading

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

On Wed, 2003-10-01 at 15:30, Lubos Lunak wrote:
>  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. 
An what if this is not TYPE_TOOLBAR window? You think only toolbar
windows need it? 

> 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), 
It seems that's what I want - WM shouldn't affect, it should just do and
control correctness.

> 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").
It is because the authors of the protocols didn't think about extending
them(as you do right now). As being said, by specifying simple
non-tightly related features you can easily extend anything - just add
more features.

> 
> >
> > > > > 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?
Win32 API? Java BugParade? search for modal.

> 
> >
> > >  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?
When it is used as "this is a set of windows I block". This is
absolutely different from the definition you provided, and can't be
narrowed to it by any means.

Denis