GNOME Bugzilla – Bug 97081
Suggest to implement gdktargets as dynamic loadable module
Last modified: 2010-12-22 21:20:34 UTC
Recently, I want to write a program which can run both under console and X11, I choose gtk2 as the GUI library, and I have successfully set up gtk2 with directfb backend on my computer. But I noticed that gtk2-x11 and gtk2-directfb cannot be installed into same prefix, because some of the files are conflict with each other. And even more, I cannot have only one binary program which can dynamically choose which gdktarget to be used, it's very inconvenient for such application. And for the first stage, I suggest to rename /usr/lib/gtk-2.0 to a gdktarget specific name, ie. /usr/lib/gtk-x11-2.0 for gtk2 with x11 gdktarget and /usr/lib/gtk-directfb-2.0 for gtk2 with directfb gdkgarget. This can resolve the file conflict problem and make the both version of gtk2 happy in same prefix.
If it's possible, I suggest to make this fix for both gtk2-2.0.x and gtk2-2.1.x.
Right now, what is recommended is to install linux-fb with a different prefix. If you do that, then things should work fine because the libraries and .pc files are namespaced. - Making it possible to use a different directory inside $libdir is, as a new feature, not really possible before 2.4. I don't see renaming the X11 directory, since it will break makefiles for externally installed modules; I think we'd just make a different directory for non-default ports. (Actually, perhaps we should extend the module lookup algorithm instead, though we already have architecture, version, and module type in the search path...) - Doing it possible to dynamically load a different GDK requires major reworking inside GDK and the earliest it could conceivably be done is for GTK+-2.6 even if there was a volunteer who who wanted to do the work.
I wrote a patch to move /usr/lib/gtk-2.0 to /usr/lib/gtk-$(gdktarget)-2.0 and /etc/gtk-2.0/gtk.immmodules /etc/gtk-2.0/gtk-$(gdktarget).immodules. And /usr/bin/gtk-demo to /usr/bin/gtk-demo-$(gdktarget), /usr/bin/gtk-query-immmodules-2.0 to /usr/bin/gtk-query-immodules-2.0-$(gdktarget) while I noticed that /usr/lib/gtk-2.0/loaders/* are identical, so this directory is not moved. I think we may write a script to config the default gtk system. This script should do following things: ln -sf /usr/lib/gtk-$(gdktarget)-2.0/include /usr/lib/gtk-2.0/include ln -sf /usr/lib/gtk-$(gdktarget)-2.0/modules /usr/lib/gtk-2.0/modules ln -sf /usr/lib/gtk-$(gdktarget)-2.0/2.0.0/immodules /usr/lib/gtk-2.0/2.0.0/immodules ln -sf /usr/lib/gtk-$(gdktarget)-2.0/2.0.0/engines /usr/lib/gtk-2.0/2.0.0/engines ln -sf /usr/bin/gtk-query-immodules-2.0-$(gdktarget) /usr/bin/gtk-query-immodules-2.0 ln -sf /usr/bin/gtk-demo-$(gdktarget) /usr/bin/gtk-demo ln -sf /usr/lib/pkgconfig/gdk-$(gdktarget)-2.0.pc /usr/lib/pkgconfig/gdk-2.0.pc ln -sf /usr/lib/pkgconfig/gtk+-$(gdktarget)-2.0.pc /usr/lib/pkgconfig/gtk+-2.0.pc This will resolve the binary compatibility issue.
Created attachment 11963 [details] [review] The patch is against gtk+-directfb-2.0.6 (published on www.directfb.org).
For now, you just have to use different prefixes for different targets.
I don't think it makes much sense to install different backends in the same prefix, as long as they are not dynamically switchable.
What needs to happend to allow the backend to be dynamically loaded. This will really help directfb since the apps would not need to be recompiled. Because of all the symbol magic etc its not clear to me how tied gtk is to the the gdk backend.
grep for GDK_WINDOWING_X11 to find backend-specific code in gtk/*.c
There is very little is that all there is to it. Okay I'll put this on my todo list. I'm going to be able to do a bit of work on gtk starting next week. I've been buried in webkit till now. After I fix command line args :)
Will look into updating the patch…
I'm a bit worried that the current patch doesn't keep backward compatibility with previous gtk.immodules filenames. Also it doesn't sound entirely unconceivable to me that a gtk immodule would work with both the x11 and directfb backends, such as a keypad entry immodule. So I think it still makes sense to allow the non-windowing-system-versionned directory and immodules files.
For 3.0, we will instead have the possibility to compile multiple backends into the same libgdk.so and choose a backend at runtime.