GNOME Bugzilla – Bug 673396
X11Screen must be imported before getting the default screen in order to call get_window_manager_name()
Last modified: 2015-11-14 09:01:05 UTC
To call gdk_x11_screen_get_window_manager_name(), you must not only import X11Screen even though you have an X11Screen object (see 1), but you must also do so before getting the default screen (see 3). The former is no big deal; the latter is a bit of a drag. ============= 1 ============= $ python >>> from gi.repository import Gdk >>> display = Gdk.Display.get_default() >>> screen = display.get_default_screen() >>> screen.get_window_manager_name() Traceback (most recent call last):
+ Trace 229997
============= 2 ============= $ python >>> from gi.repository import Gdk >>> from gi.repository.GdkX11 import X11Screen >>> display = Gdk.Display.get_default() >>> screen = display.get_default_screen() >>> screen.get_window_manager_name() 'Mutter' ============= 3 ============= $ python >>> from gi.repository import Gdk >>> display = Gdk.Display.get_default() >>> screen = display.get_default_screen() >>> from gi.repository.GdkX11 import X11Screen >>> screen.get_window_manager_name() Traceback (most recent call last):
Confirming with GNOME 3.4. Note that it is sufficient to do "from gi.repository import GdkX11", which will do the necessary initialization. This has some resemblence to bug 656314, but it is still different because the Gdk typelib does not depend on the GdkX11 one. I don't have an off-hand idea how to fix this, though.
We've run into this before. It is sort of like C headers. If you don't import it the runtime doesn't know about it so you kind of get screwed. First fix is to print out a warning if an unknown object is returned. Second fix is to have glib somehow tell you which lib was returned and load the gi information if it hasn't already. GLib should be able to do this if it is actually an object and not just a struct. A hack would be to have a arch dependent override that understood which gi libs to load when importing Gdk. This of course does not work for gstreamer which will give you interfaces to underlying objects where sometimes you wish to manipulate the underlying object. Might be worth it for Gdk though.
*** This bug has been marked as a duplicate of bug 656314 ***
Reopening, since as stated above loading the dependencies as proposed in bug 656314 wont fix this. We could just try to import GdkX11 in the Gdk overrides. Seems like the easiest fix. Or maybe make GdkX11 a typelib dependency on supported platforms in GTK+? This would also fix it after bug 656314 gets fixed.
Created attachment 312622 [details] [review] Try to import GdkX11 in Gdk overrides pygobject will not provide GdkX11 instances until the namespace is loaded so try to load it in the overrides. This makes Gdk.Display.get_default() return a GdkX11.X11Display instead of a dummy Gdk.Display subclass instance.
Review of attachment 312622 [details] [review]: This may be a stupid question as it is a bit out of my knowledge base, but are there any side effects of doing this on a system where something like wayland is being used but an X11 fallback is available?
(In reply to Simon Feltman from comment #6) > Review of attachment 312622 [details] [review] [review]: > > This may be a stupid question as it is a bit out of my knowledge base, but > are there any side effects of doing this on a system where something like > wayland is being used but an X11 fallback is available? Afaics loading GdkX11 will just load the typelib which like Gdk-3.0 depends on libgdk-3.so.0. It's just some gi information split out in a separate typelib.
Pushed to master: https://git.gnome.org/browse/pygobject/commit/?id=6a26d3f2b25b3fbbd87def14f1df17b96ed23a0d