Hi, I have a two part browser plugin that I have written several years ago. The part that resides in /usr/lib/mozilla/plugins calls an external application (the other part), and passes the window XID it gets via the Netscape browser API. This external application was written for GTK 2.x and worked well
At the time, I needed the parent window geometry in advance in order to properly place button widgets inside, arranged into multiple rows if needed. So, I had this code in the GTK app: #if GTK_CHECK_VERSION(2,24,0) GdkWindow *fw = gdk_x11_window_foreign_new_for_display(gdk_display_get_default(), nw); #else GdkWindow *fw = gdk_window_foreign_new(nw); #endif gdk_window_get_geometry(fw, &x, &y, &w, &h, &depth); printf("create_pdf_browser xembed parent size w %d h %d\n", w, h); window1 = gtk_plug_new(nw); Sometimes, I notice bad behavior on different GTK / GLIB versions than I originally written for and tested on. The external application simply starts consuming 100% CPU, spinning in gtk_main(). Usually, the plugin is used by an in-house mini-browser based on webkitgtk. The 100% CPU usage sounds like this: https://mail.gnome.org/archives/gtk-app-devel-list/2002-June/msg00189.html Is it legal to call gtk*foreign_new* on the same window ID before gtk_plug_new()? My first guess was that Webkit removes the XEMBED window for some reason, causing the 100% CPU because the effect. But I attach a callback to delete_event of the "window" I get from gtk_plug_new() so it shouldn't be the case. What else may cause this behavior in the XEMBED client? Thanks in advance, Zoltán Böszörményi _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list