Re: WM_TRANSIENT_FOR and _NET_WM_STATE_MODAL inconsistancy

[Havoc Pennington <hp redhat com>]

On Tue, 2003-12-23 at 03:27, Ben Jansens wrote:
> 
> 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.

Probably true. 

Here is the metacity definition, which may be broken:

#define WINDOW_HAS_TRANSIENT_TYPE(w)                    \
          (w->type == META_WINDOW_DIALOG ||             \
	   w->type == META_WINDOW_MODAL_DIALOG ||       \
           w->type == META_WINDOW_TOOLBAR ||            \
           w->type == META_WINDOW_MENU ||               \
           w->type == META_WINDOW_UTILITY)

#define WINDOW_TRANSIENT_FOR_WHOLE_GROUP(w)             \
         ((w->xtransient_for == None ||                 \
           w->transient_parent_is_root_window) &&       \
          WINDOW_HAS_TRANSIENT_TYPE (w))


> 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.

> 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.

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.

Havoc