Description of problem: calling the following line from Python > from gi.repository import Gtk immediately tries to initialize Gtk. If the system has no display output or no X, it fails with RuntimeError: Gtk couldn't be initialized This behaviour is unacceptable for a library as it makes it impossible to import a file with this line from anywhere outside of X environment (unittest or rpmbuild for example). Version-Release number of selected component (if applicable): rawhide+koji repo on the 21st of January 2013 gtk3-devel-3.7.6-1 pygobject3-3.7.4-1 gobject-introspection-devel-1.35.4-1 How reproducible: Always Steps to Reproduce: [msivak@euryale initial-setup]$ DISPLAY= python Python 2.7.3 (default, Jul 24 2012, 10:05:38) [GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from gi.repository import Gtk Actual results: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/gi/importer.py", line 76, in load_module dynamic_module._load() File "/usr/lib64/python2.7/site-packages/gi/module.py", line 224, in _load overrides_modules = __import__('gi.overrides', fromlist=[self._namespace]) File "/usr/lib64/python2.7/site-packages/gi/overrides/Gtk.py", line 1533, in <module> raise RuntimeError("Gtk couldn't be initialized") RuntimeError: Gtk couldn't be initialized Expected results: No output and Gtk initialized with the first Gtk call (or using Gtk.init() which is currently unavailable)
This has been the traditional behaviour of the gtk python bindings since forever, afaik
Well, that may be, but it still is wrong. All the other languages I checked have separate init call. There is even Gtk.init available in Python, it just gets called too early. /usr/lib64/python2.7/site-packages/gi/overrides/Gtk.py contains this: initialized, argv = Gtk.init_check(sys.argv) sys.argv = list(argv) if not initialized: raise RuntimeError("Gtk couldn't be initialized") I understand the reasons for the exception (fallback to different UI mode), but any Python library that has side-effects in it's initialization is really wrong. The reason is we have no equivalent of .h files, but still want to access constants and control when the initialization happens (and if it should happen at all). Moreover, tools like python-nose (unittest launcher) have to import files to take a look at the definitions there, but are not executing anything. Gtk's current behaviour breaks it. Is it possible to modify Gtk so it does not throw an exception when it is imported and (if such compatibility is really needed) tries the init silently again when a library call really needs it? If anybody needs the detection, he should call Gtk.init explicitly and catch the error where it fits his project codebase. The exception used in overrides is way too generic and it is not really nice to have such a generic try/except block around all imports (because it can be somebody else's library that accesses Gtk). And import Gtk can be in lots of files, on the other hand.. Gtk.init is usually a single line in the project.
(In reply to comment #2) > > Is it possible to modify Gtk so it does not throw an exception when it is > imported and (if such compatibility is really needed) tries the init > silently again when a library call really needs it? > I don't know, I don't do python. But I am very much convinced that compatibility is needed.
Created attachment 685139 [details] optionally disable the implicit Gtk.init using env variable This is probably the least intrusive change that will add the behaviour we want without compromising the backward compatibility. I still think this should be changed properly in the future, but this is the best we can do at this moment.
This should really be filed upstream with pygobject. I tried searching the bugzilla there but couldn't find anything. Making one now.
https://bugzilla.gnome.org/show_bug.cgi?id=692300
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
fixed upstream and in 3.8.0