GNOME Bugzilla – Bug 678673
Does not handle GFile in signal arguments
Last modified: 2013-04-14 11:13:29 UTC
Created attachment 217089 [details] Test Python script using Gtk.Application with Gio.ApplicationFlags.HANDLES_OPEN When using GtkApplication without command line arguments in Python, it works fine. When using Gio.ApplicationFlags.HANDLES_OPEN and passing arguments along `sys.argv` to g_application_run(), the following error occurs: /opt/gnome/lib64/python2.7/site-packages/gi/types.py:47: Warning: g_value_get_boxed: assertion `G_VALUE_HOLDS_BOXED (value)' failed return info.invoke(*args, **kwargs) The 'open' callback gets an empty list for the files and thus there is nothing for the application to open, but, the n_files comes back with the correct number of arguments that were passed in. A test application attached.
I'm experiencing the same problem, although I worked around it by using HANDLES_COMMAND_LINE instead: https://github.com/robru/gottengeography/blob/master/gg/app.py#L45
Confirming.
Some debugging notes, mostly for myself. I changed the test program to use Gio.Application and print sys.argv at start. $ PYTHONPATH=. jhbuild run gdb --args python3 /tmp/testapplication.py foo [...] sys.argv: ['/tmp/testapplication.py', 'foo'] Breakpoint 1, g_application_run (application=0xd281d0, argc=2, argv=0xd59bc0) at gapplication.c:1538 1538 g_return_val_if_fail (G_IS_APPLICATION (application), 1); (gdb) p argv $1 = (char **) 0xd59bc0 (gdb) p argv[0] $2 = 0xd59be0 "/tmp/testapplication.py" (gdb) p argv[1] $3 = 0xc3e730 "foo" This looks alright. argc has the correct value, and argv is a proper char* array. So the problem is not the marshalling of sys.argv. The warning happens when g_application_open calls 1447 g_signal_emit (application, g_application_signals[SIGNAL_OPEN], (gdb) n /home/martin/upstream/pygobject/gi/types.py:47: Warning: g_value_get_boxed: assertion `G_VALUE_HOLDS_BOXED (value)' failed return info.invoke(*args, **kwargs) [] 1 So the problem is apparently that GFile is not being handled correctly as an array element in a signal callback.
A workaround seems to implement Application.do_open yourself instead of connecting to the 'open' signal, for example: from gi.repository import Gtk, Gio class DemoApp(Gtk.Application): def __init__(self): super(DemoApp, self).__init__() self.connect('activate', self.on_activate) def do_open(self, files, n_files, hint): print('do open', files) self.new_window() def on_activate(self, *args): print('activate', args) self.new_window() def new_window(self): win = Gtk.Window() win.set_application(self) win.set_title('Demo') win.add(Gtk.Label("foo")) win.resize(500, 500) win.show_all() self.add_window(win) if __name__ == '__main__': import sys app = DemoApp() app.set_application_id('org.demo.app') app.set_flags(Gio.ApplicationFlags.HANDLES_OPEN) app.run(sys.argv)
Verified the original bug no longer exists.