After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 124525 - Lacks API for group transients from EWMH
Lacks API for group transients from EWMH
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
2.2.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2003-10-14 05:42 UTC by Gregory Merchan
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Gregory Merchan 2003-10-14 05:42:10 UTC
The EWMH specify setting WM_TRANSIENT_FOR to the root window or None to
indicate that a window is transient for other windows in its group. This is
needed for palettes that should stay above all document windows of an app
and application modal dialogs, for example.

The function gtk_window_set_transient_for() just returns when no parent is
specified and gdk_window_set_transient_for() will not alter the hint without
a valid GdkWindow argument, so neither can be used for this.
Comment 1 Havoc Pennington 2003-10-14 14:58:04 UTC
metacity at least just interprets the WM_TRANSIENT_FOR for the root
window as a legacy way to say _NET_WM_WINDOW_TYPE_DIALOG.
If you have a window type hint set, I believe metacity will ignore the 
transient for root window hint. This is what I believe the spec should
say as well, really, don't know what it currently says.
Comment 2 Gregory Merchan 2003-10-14 17:25:47 UTC
The most recent copy I have from anoncvs says:
> _NET_WM_STATE_MODAL indicates that this is a modal dialog box.  
> If the WM_TRANSIENT_FOR hint is set to another toplevel window,
> the dialog is modal for that window; if WM_TRANSIENT_FOR is not
> set or set to the root window the dialog is modal for its window
> group.

And later says:
> If the WM_TRANSIENT_FOR property is set to None or Root window,
> the window should be treated as a transient for all other windows
> in the same group.  It has been noted that this is a slight ICCCM
> violation, but as this behavior is pretty standard for many
> toolkits and window managers, and is extremely unlikely to break
> anything, it seems reasonable to document it as standard.

The group is not specified, but presumably means the group
determined by WM_HINTS.window_group.

There's a problem here in that WM_TRANISENT_FOR=None is not the same
as not setting the hint. If you call:

  XSetTransientForHint ((Display *) d, (Window) w, (Window) None);

And then check the property with xprop, you'll see:

  WM_TRANSIENT_FOR(WINDOW): window id # 0x0

I just took another look at the property tables I'm working on, and
non-modal WM_TRANSIENT_FOR={None|Root} is redundant with palettes
and other _NET_WM_WINDOW_TYPE_UTILITY windows.

If setting _NET_WM_STATE_MODAL without setting WM_TRANSIENT_FOR
makes a window application modal, then this may be NOTABUG - I
don't know of any use then for WM_TRANSIENT_FOR={None|Root}.
Comment 3 Owen Taylor 2003-11-11 22:44:45 UTC
Supporting EWMH features to support EWMH features is not
interesting.

If you want to get an addition to the GTK+ API, you need
to explain it in terms of:

 - Why application authors would use it
 - Why they can't do it with the current API

References to equivalent concepts on other operating systems
may be useful as well, since if the API affects app behavior
in a significant way, then it really needs to be implemented
for other GTK+ ports as well.

If you want to rephrase this RFE in those terms, feel
free to reopen.