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 119375 - Add way to get default group leader window
Add way to get default group leader window
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
2.2.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 59724 68557
 
 
Reported: 2003-08-07 21:48 UTC by Owen Taylor
Modified: 2011-02-04 16:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (5.52 KB, patch)
2003-08-08 21:34 UTC, Matthias Clasen
none Details | Review
new patch (4.53 KB, patch)
2003-11-09 00:22 UTC, Matthias Clasen
none Details | Review

Description Owen Taylor 2003-08-07 21:48:05 UTC
We should make the default leader window for the application
a GdkWindow and have a way of retrieving it, maybe:

GdkWindow *gdk_display_get_default_group (GdkDisplay *display);

Other possibly useful additions to GDK in this area

 * Make gdk_window_set_group (window, NULL); restore the
   window back to the default group leader
 * gdk_window_get_group()
Comment 1 Owen Taylor 2003-08-07 22:38:15 UTC
It would be nice to fix at least the simplest parts of 
bug 68557 for 2.4, which would require this.
Comment 2 Matthias Clasen 2003-08-08 21:33:21 UTC
Here is a patch, untested beyond compilation.
Comment 3 Matthias Clasen 2003-08-08 21:34:01 UTC
Created attachment 19046 [details] [review]
patch
Comment 4 Owen Taylor 2003-11-05 16:13:06 UTC
I dislike the use of gdk_window_foreign_new_for_display() 
here ... gdk_window_foreign_new_for_display() needs to do
several round trips to the server and is really not meant
for windows that GDK is creating itself.

I think it shouldn't be too hard to make display_x11->leader_window
a GdkWindow and just use gdk_window_new() for it. 
Comment 5 Matthias Clasen 2003-11-05 22:14:17 UTC
Hmm, we already use gdk_window_foreign_new for self-created windows 
(cf motif_drag_gdk_window). Changing to gdk_window_new will

a) incur some overhead, e.g. we would create a focus window, map it, 
add a bunch of unnecessary properties to the leader, etc.

b) not entirely trivial, since it would be called while the display is
not completely setup yet. gdk_window_new () assumes the display is
completely initialized, e.g. it calls check_leader_window_title()
which assumes leader_window to be already there). These complications 
are the reason why I went for the lazy creation of leader_gdk_window
in the first place. 

If you want to avoid gdk_window_foreign_new despite a), we should
probably go to a even more lazy initialization. That would mean 
replacing all direct uses of display->leader_window by 
_gdk_x11_display_get_leader_window () though, which would have to
create the window if necessary.
Comment 6 Matthias Clasen 2003-11-09 00:22:19 UTC
Created attachment 21303 [details] [review]
new patch
Comment 7 Matthias Clasen 2003-11-09 00:24:28 UTC
New patch which avoids the use of gdk_window_foreign_new_for_display
(). This could probably be simplified by getting rid of leader_window
altogether. Or rather, get rid of leader_gdk_window and make
leader_window a GdkWindow.
Comment 8 Owen Taylor 2003-12-09 17:49:46 UTC
Patch looks fine to commit