After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 692300 - allow skipping automatic Gtk.init_check
allow skipping automatic Gtk.init_check
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2013-01-22 15:11 UTC by Colin Walters
Modified: 2013-01-30 07:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Do not immediately initialize Gdk and Gtk on import (1.77 KB, patch)
2013-01-23 06:23 UTC, Martin Pitt
committed Details | Review

Description Colin Walters 2013-01-22 15:11:13 UTC
Executive summary: People want some option to allow "import Gtk" to not cause the side effect of attempting to connect to X.

See https://bugzilla.redhat.com/show_bug.cgi?id=902401

Previous discussion from pygtk:
https://bugzilla.gnome.org/show_bug.cgi?id=157422
https://bugzilla.gnome.org/show_bug.cgi?id=316877
Comment 1 Martin Pitt 2013-01-22 17:15:03 UTC
I don't quite like this myself, but we can't just drop it (as suggested in the downstream bug) as that would break pretty much every Python GTK program out there. Oh the joy of backwards compatibility...

I'm fine with testing an environment variable, though. That might be something like $GTK_SKIP_AUTOINIT, or we could even go as far as skipping the initialization if we don't have a $DISPLAY?
Comment 2 Matthias Clasen 2013-01-22 17:36:52 UTC
Looking for DISPLAY might be a pragmatic solution, indeed
Comment 3 Paolo Borelli 2013-01-22 18:29:31 UTC
On the other hand looking at DISPLAY would not be a cross platform way to skip init... but maybe that's not and actual problem
Comment 4 Martin Pitt 2013-01-23 06:22:22 UTC
Paolo: Oh, you mean if you run GTK on e. g. a framebuffer or Wayland instead of X.org? Good point.

I just thought about this again. What we really do need to keep for compatibility is the call to Gtk.init_check(), but we could drop the exception raising if it fails. If programs really care they could check Gtk.initialized after importing.

The main drawback is that the output becomes really unintelligible if you try and start a Gtk program without a $DISPLAY. You get a neverending stream of Gtk-CRITICALS and then a segfault, but no really well-defined exception or failure mode.

So it would help if we moved the "initialized" check later. I tried to add it to Gtk.main(), but that usually comes way too late. A reasonable compromise might be to move it to Gtk.Window.__init__()? That might still cause a few warnings if some widgets are built before that, but it limits the performance impact having a Python constructor override and the initialized check to Windows instead of putting it on all widgets.
Comment 5 Martin Pitt 2013-01-23 06:23:16 UTC
Created attachment 234169 [details] [review]
Do not immediately initialize Gdk and Gtk on import

What do people think about this patch?
Comment 6 Tomeu Vizoso 2013-01-23 08:52:23 UTC
Wonder if the check could be done somewhere in the main loop, as the event loop is a (bit) more fundamental part of Gtk+ apps than GtkWindow.
Comment 7 Martin Pitt 2013-01-30 06:34:17 UTC
> Wonder if the check could be done somewhere in the main loop

That's what I tried at first indeed, but I got tons of criticals and a segfault during initializing widgets, way before the program got to the main loop.
Comment 8 Simon Feltman 2013-01-30 07:03:56 UTC
Review of attachment 234169 [details] [review]:

The patch seems fine. The important thing is we can keep compatibility without having an exception raised during module import and we avoid as many Gtk-CRITICALS as possible.
Comment 9 Martin Pitt 2013-01-30 07:15:04 UTC
Comment on attachment 234169 [details] [review]
Do not immediately initialize Gdk and Gtk on import

OK, thanks for reviewing! Let's just go with that for now, and see how it goes.