Re: WM_TRANSIENT_FOR and _NET_WM_STATE_MODAL inconsistancy

[Lubos Lunak <l lunak suse cz>]

Dne út 23. prosince 2003 15:54 Havoc Pennington napsal(a):
> On Tue, 2003-12-23 at 03:27, Ben Jansens wrote:
> > It is my opinion that if TYPEs are being used to define transiency, and
> > transiency to define TYPEs, that we have a clash/redundancy between these
> > properties.
> > If the DIALOG type can be assumed based on transiency, then why does it
> > exist at all? Why don't dialog windows simply specify NORMAL and a
> > WM_TRANSIENT_FOR, and get treated accordingly?
>
> Assuming DIALOG based on transiency is a legacy guess; metacity only
> does it if the type hint is unset. i.e. if you have NORMAL with
> TRANSIENT_FOR, it's decorated as a normal window then made transient.
> But no type hint and TRANSIENT_FOR is taken as a dialog, because
> historically that was the convention.

 Not exactly actually, there are enough cases where transient windows in old 
apps aren't dialogs but something else (e.g. the menu window in ImageMagick's 
display).

> > ** KWin People:
> > How do you view DIALOG type windows and transiency? Do KWin and Metacity
> > agree on which are "typically transient type"s? What corner cases does
> > QT/KDE/KWin bring to the table regarding the transiency, group, and
> > modality hints?

 Currently KWin doesn't make dialogs modal to the window group if it doesn't 
have the transient hint set at all, but I guess I should make it work the 
same way like Metacity - it makes sense, and it's in the spec after all (and 
the spec actually says that transient for root or None is an ICCCM violation, 
so I suppose the proper EWMH way would be setting only MODAL and not setting 
transient hint to make it group transient). As for the other window types, 
I'm not sure, but I think I'd probably force the same window types as 
Metacity to be group transient if they don't have the hint set.

> > Is there any chance of superceding the current WM_TRANSIENT_FOR and
> > group leader hints with something properly engineered to allow for more
> > complex and useful relationships between windows with clearly defined
> > rules? Being able to put a window into multiple (possibly partially
> > overlapping) groups and simply be transient/modal for one or more of them
> > would be a lot more useful than the current system. :) I'm sure better
> > solutions abound.

 Feel free to suggest one. You'll find out it won't be that simple :-/.

>
> There was a fair bit of discussion of this earlier, people were worried
> about complexity (for both WM author and user). But some changes may be
> warranted.

-- 
 Lubos Lunak
 KDE Developer