Re: WM_TRANSIENT_FOR and _NET_WM_STATE_MODAL inconsistancy



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]