GNOME Bugzilla – Bug 316877
Make it possible to import gtk without a DISPLAY set
Last modified: 2006-08-14 13:06:05 UTC
Distribution/Version: Gentoo At a console without X running, start the python interpreter. Type the following statement: import gtk I get the following error. RuntimeError: could not open display. I do not see the correlation between populating namespaces and X running, or any other program for that matter. When I import a module, I expect my namespace to be populated with the names in the imported module, irrespective of whether third party applications are running or not. For example, I do not believe I need to have X running to check which version of PyGTK I have installed from the Python interpreter.
I was thinking about this the other day. What we need to do is to be able to import gtk when a $DISPLAY is not found. A warning should probably be written on stderr, but it should still be possible to check the version numbers for example. The proper solution is probably to write bindings for the relevant gtk_init_* functions and move them to __init__.py, where it is easier to tweak this kind of stuff.
Oh, please, this not a blocker. But I agree with johan.
Fixed in CVS: Checking in ChangeLog; /cvs/gnome/gnome-python/pygtk/ChangeLog,v <-- ChangeLog new revision: 1.1398; previous revision: 1.1397 done Checking in gtk/__init__.py; /cvs/gnome/gnome-python/pygtk/gtk/__init__.py,v <-- __init__.py new revision: 1.35; previous revision: 1.34 done Checking in gtk/gtk.override; /cvs/gnome/gnome-python/pygtk/gtk/gtk.override,v <-- gtk.override new revision: 1.352; previous revision: 1.351 done Checking in gtk/gtkmodule.c; /cvs/gnome/gnome-python/pygtk/gtk/gtkmodule.c,v <-- gtkmodule.c new revision: 1.64; previous revision: 1.63 done
But by doing this, you make it impossible from an app to be able to sanely handle the case of the display not being there -- while you obviously wouldn't be able to throw up a dialog without a DISPLAY, you could previously import gtk and if that failed, give a nice message on the command line. You can't programatically check for a warning being printed to stdout and so the import succeeds and your app then goes on to fail in other and different ways.
Jermey: Okay, I didn't think of that use case. What I was trying to solve here was a build issue, to be able to check the version numbers and the presence of the gtk module without requiring a DISPLAY. Would a variable indicating if gtk_init_check() succeeded be enough to solve this for you?
A related use case is supporting x11 on OS X where x11 may not be running even when the user is logged in to the OS X gui. That said would an existing call such as gtk.gdk.display_get_default() work to check for a valid X11 connection.
It could work, but it then requires going through and changing any existing code that works like this. I know that at least a lot of our pygtk config tools and the like take advantage of the way things previously worked and I've seen it in other pygtk apps as well.
(In reply to comment #7) > It could work, but it then requires going through and changing any existing > code that works like this. I know that at least a lot of our pygtk config > tools and the like take advantage of the way things previously worked and I've > seen it in other pygtk apps as well. I'm afraid there's not really possible to solve this for both use cases I mentioned. A feature was added to PyGTK, which means that we do not raise an ImportError if a display is not found. Programs depending on the old behavior needs to be updated, one way or another. It should probably be documented somewhere though.
So to support something which didn't previously work, you've broken existing applications :( Just documenting it doesn't fix the underlying problem. A better way to support this might be to add the functionality to the pygtk module -- then, applications which never worked before have a way to get what they want but you haven't done so in a way that breaks existing apps. It's not going to be as straight-forward, but it maintains the stable interface.
I changed the printout into a warning, so it's possible to catch it end user applications. I added a section http://live.gnome.org/PyGTK/WhatsNew210 which describes how to catch the error in 2.10. Checking in ChangeLog; /cvs/gnome/pygtk/ChangeLog,v <-- ChangeLog new revision: 1.1607; previous revision: 1.1606 done Checking in NEWS; /cvs/gnome/pygtk/NEWS,v <-- NEWS new revision: 1.72; previous revision: 1.71 done Checking in gtk/__init__.py; /cvs/gnome/pygtk/gtk/__init__.py,v <-- __init__.py new revision: 1.50; previous revision: 1.49 done