GNOME Bugzilla – Bug 410010
Adding foreign new for X displays
Last modified: 2010-04-01 03:43:25 UTC
Hello. It would be great to have a "GdkDisplay *gdk_x11_foreign_new_xdisplay (Display *xdisplay)" to wrap an already opened X Display connection. This can be used to have GDK, Xlib or another library that uses it, to draw on the same X resources without races. This is needed for a GTK+ skin for KDE/Qt apps that I am working on.
Created attachment 82951 [details] [review] gdk_x11_foreign_new_xdisplay patch
Created attachment 82952 [details] test case (handle events with Xlib)
Created attachment 82953 [details] test case (handle events with GDK)
Unable to apply the patch... Ricardo, can you please check the problem? Thanks :) Hmm... Looks like a unified diff to me... can't find file to patch at input line 7 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Only in gtk+-2.10.9-mod/gdk: .deps |Only in gtk+-2.10.9-mod/gdk/directfb: .deps |Only in gtk+-2.10.9-mod/gdk/directfb: Makefile |diff -ur gtk+-2.10.9/gdk/gdkaliasdef.c gtk+-2.10.9-mod/gdk/gdkaliasdef.c |--- gtk+-2.10.9/gdk/gdkaliasdef.c 2007-01-22 16:02:44.000000000 +0000 |+++ gtk+-2.10.9/gdk/gdkaliasdef.c 2007-02-20 04:21:16.000000000 +0000 -------------------------- File to patch:
Might be worthwhile to point to the mailing list discussion of this idea: http://mail.gnome.org/archives/gtk-devel-list/2007-February/msg00005.html
So, here goes a patch against GTK+ 2.10.2. Btw, the gtk4qt style if someone is interested is hosted at http://gtk4qt.sourceforge.net/ . It works pretty well though there is still quite a lot of work to make thing render nicely just as if they were GTK+ apps. Its stalled for the moment, as there is no point in working on it, if GTK+ doesn't ship with something, as the wrapper function proposed here, to expose a way to re-use a Display connection for the purpose of issuing drawing commands. We may want to change the functions name and arguments... The point of re-using a Display connection is so we can issue command to Windows/Pixmaps we share with another program without races (those commands would be mainly drawing commands of course). Allowing the program to connect to Display events is likely always to end up badly. We probably should drop the argument and deploy this as just a dummy Display connection. Would be nice if we could get a GDK expert to look into this.
Created attachment 89009 [details] [review] 2.10.2 patch
Btw, Qt allows for wrapping an existing Display connection at the initialization, which is why gtk-qt-engine works (then they make use of gdkx facilities to share Windows and Pixmaps, which Qt lacks).
Someone added such calls already. Closing.