On Wed, Oct 01, 2003 at 02:54:45PM +0200, Lubos Lunak wrote: > On Wednesday 01 of October 2003 13:50, Dominik Vogt wrote: > > On Wed, Oct 01, 2003 at 11:32:52AM +0200, Lubos Lunak wrote: > [snip] > > > > > 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. > > > > I'd rather do without that "feature". Handling trees of > > transients is already almost impossible to handle gracefully > > without multiple paths in the window relationships :-P > > Why should there be multiple paths? KWin has a tree for such relations, and > there are no loops or multiple paths. On the other hand, I have to admit the > code for handling (and checking) that was a paint to write :-/. > > Anyway, I couldn't come up with any idea for solving my problem better than > extending WM_TRANSIENT_FOR. But let me first explain the problem, maybe > somebody will known something better. The problem is roughly like this: http://www.freedesktop.org/standards/wm-spec/1.3/ar01s07.html#id2829509 Does this not solve your problem? Ben
Attachment:
pgpBUj6t8slvE.pgp
Description: PGP signature