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 324876 - Add function to get toplevel of a GtkPlug
Add function to get toplevel of a GtkPlug
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
unspecified
Other Linux
: Normal enhancement
: Small API
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-12-23 13:26 UTC by Bastien Nocera
Modified: 2016-05-24 11:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gtk-plug-get-toplevel.patch (3.74 KB, patch)
2006-02-08 16:44 UTC, Bastien Nocera
none Details | Review
patch that actually works (4.60 KB, patch)
2006-04-27 14:47 UTC, Christian Persch
none Details | Review
gtk+-set-plug-toplevel-automatically.patch (6.40 KB, patch)
2006-10-12 21:06 UTC, Bastien Nocera
needs-work Details | Review

Description Bastien Nocera 2005-12-23 13:26:54 UTC
Right now, when creating a GtkPlug, the developer has to use X himself to get the toplevel window of a GtkPlug.
This would be useful to be able to parent dialogues properly for the GtkPlug/GtkPlug's toplevel window.
Comment 1 Matthias Clasen 2005-12-27 00:02:11 UTC
Do you have a patch, Bastian ?
Comment 2 Bastien Nocera 2005-12-27 13:48:14 UTC
I have a patch which tries to do that for Totem, but fails miserably, I have no idea why. The patch is in bug #323759
Comment 3 Bastien Nocera 2006-01-23 18:44:19 UTC
Fixed in Totem. The function is totem_gtk_plug_get_toplevel() in this patch:
http://cvs.gnome.org/viewcvs/totem/src/totem-mozilla-viewer.c?r1=1.28&r2=1.29

My guess now is whether we should implement gtk_plug_get_toplevel(), or rather a gtk_window_set_transient_for_plug () which is likely to be the main reason to use this function.
Comment 4 Bastien Nocera 2006-02-08 16:44:50 UTC
Created attachment 58948 [details] [review]
gtk-plug-get-toplevel.patch
Comment 5 Christian Persch 2006-04-27 14:47:12 UTC
Created attachment 64398 [details] [review]
patch that actually works
Comment 6 Bastien Nocera 2006-04-27 15:03:48 UTC
Ha, missed exporting the symbols, sorry.
Comment 7 Bastien Nocera 2006-10-12 21:06:36 UTC
Created attachment 74595 [details] [review]
gtk+-set-plug-toplevel-automatically.patch

Same as the previous patch, but also automatically looking at whether the toplevel window is a GTkPlug or not, and work appropriately. It would also fix the use case in bug 359066
Comment 8 Owen Taylor 2007-04-25 12:41:41 UTC
+ * Return value: a newly-created #GdkWindow with a reference count of 1, or
+ * NULL if the #GtkPlug is not embedded.

Is slightly wrong, since the GdkWindow isn't necessarily newly created,
and in fact, never has a reference count of 1 though the caller shouldn't
worry about the reference count in any case.

- This patch will trigger a known bug in foreign window handling, where
  a foreign window where you don't select for structure-change events
  will get leaked. (This is the "XID table shouldn't reference" issue)

- The way that the patch checks for toplevel windows isn't correct
  (I'm not sure how it passed testing. It would work with compiz,
  but I dont' see how it would work with a reparenting window manager
  like Metacity)

  See activate-window in:
  http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-ui.c

  for the correct technique.

- You *must* always use an error trap when walking around in windows
  not owned by GTK+. Again, see the code referenced above.