On Mon, Dec 22, 2003 at 11:23:05AM -0500, Havoc Pennington wrote: > Hi, > > In metacity WM_TRANSIENT_FOR as None/Root _or_ unset are treated as the > same thing, if the window is known to have type DIALOG or other > typically transient type. The "set as transient for root" convention I > would consider a legacy means of saying "type DIALOG" What are these "typically transient type"s? To not have this clearly defined in the specification means that applications may or may not work in different "compliant" Window Managers. > MODAL probably only makes sense on dialogs (though the spec doesn't say > this, hmm). Anyway, to me any dialog is always transient for at least > the group if not for a particular window. If it isn't transient for then > it's probably not a dialog, but rather some sort of GIMP window or > something. ;-) This all seems very vague to me, and difficult to impossible to ensure than applications are going to work as expected. Perhaps someone could set out how all the different _NET_WM_TYPEs are expected to affect transiency and group relationships? I need to know how applications are expecting their windows to be related, not strict regulations on how to behave. 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? ** 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? 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. ben
Attachment:
pgpKsjOxV0Y2T.pgp
Description: PGP signature