On Wed, Oct 01, 2003 at 03:29:43PM +0200, Dominik Vogt wrote:
> The abuses of the transientfor hint I have already seen:
>
> - transientfor does not exist
> - transientfor mapped after the transient window
> - transientfor loops (A transient for B, B transient for A)
> - transientfor hint set to None (I think)
None is the same a Root, and means transient for its group.
- transientfor group loops :) (A is transient for group, B is transient
for same group)
> I fear I would have to add
>
> A B
> / \ /
> C D
> \ / \
> E F
>
> :-P
>
> Assuming the WM is configured to automatically raise/lower the
> whole tree of transients when one window is raised/lowered, in
> which order should the windows be stacked if window D is raised
> (lowered)?
It should keep the same stacking order as it previously was, however, the
window which was selected for lowering/raising should be raised/lowered
against its transient siblings.
> Maybe extend the window_group hint to allow a window to be a
> member of multiple window groups? To reduce the confusion, only
> the primary group should be considered for placement,
> iconification etc.
What if you don't want a primary group?
Ben
Attachment:
pgpl3E7qvgJKT.pgp
Description: PGP signature