GNOME Bugzilla – Bug 662371
Gio::DBus::Connection: Add call_[finish|sync]() with UnixFDLists.
Last modified: 2012-10-05 20:47:38 UTC
Created attachment 199617 [details] [review] Patch to add the Gio::DBus::Connection::call_[finish|sync]() methods. This patch adds the mentioned methods using the new output parameter functionality in gmmproc, thus it depends on the relevant bug.
It looks like I have not noticed this patch for ages, and I just committed an inferior commit to add these methods yesterday. However, when I revert my commit http://git.gnome.org/browse/glibmm/commit/?id=edca3b3b3da20baf9d79b4820a02bc15a08c207f and try to apply your patch, I get this gmmproc error: dbusconnection.hg:793: fail to parse Glib::VariantContainerBase call_finish(const Glib::RefPtr<AsyncResult>& res{.}, Glib::RefPtr<UnixFDList>& out_fd_list{.>>}), g_dbus_connection_call_with_unix_fd_list_finish, errthrow Use of uninitialized value $_ in substitution (s///) at ../../tools/pm/Util.pm line 63. Use of uninitialized value $_ in substitution (s///) at ../../tools/pm/Util.pm line 64. Use of uninitialized value $argCFunctionName in pattern match (m//) at ../../tools/pm/WrapParser.pm line 884. Use of uninitialized value $functionName in hash element at ../../tools/pm/DocsParser.pm line 241. Can't call method "get_return_type_for_methods" on unblessed reference at ../../tools/pm/Output.pm line 395. make[2]: *** [.stamps/dbusconnection.stamp] Error 255 make[2]: *** Deleting file `.stamps/dbusconnection.stamp' make[2]: Leaving directory `/home/murrayc/checkout/gnome/glibmm/gio/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/murrayc/checkout/gnome/glibmm'
Created attachment 224571 [details] [review] Patch to allow setting C++ output parameters from C function output parameters Yes. The reason is that the bug that was in progress (bug #651523) adding new functionality to handle setting C++ output parameters from C function output parameters crashed so it was not possible to get that functionality in gmmproc easily. This attached patch from the crashed bug would be necessary for the patch that adds the new methods to work correctly.
Created attachment 224572 [details] [review] Updated patch to add the Gio::DBus::Connection::call_[finish|sync]() methods.
Created attachment 224573 [details] [review] Updated patch to add the Gio::DBus::Connection::call_[finish|sync]() methods.
I updated the original patch adding the methods against the latest git sources.
Comment on attachment 224572 [details] [review] Updated patch to add the Gio::DBus::Connection::call_[finish|sync]() methods. For some reason the patch was added twice (browser trouble). Marking this one obsolete to avoid confusion.
I think you meant to revert the commit that adds the methods in git and then apply the patch that adds the methods in this bug. Sorry. The following patches do that.
Created attachment 224574 [details] [review] Patch to revert the git commit adding the methods.
Created attachment 224575 [details] [review] Updated patch to add the Gio::DBus::Connection::call_[finish|sync]() methods.
Thanks. Please feel free to push this.
Pushed: http://git.gnome.org/browse/glibmm/commit/?id=415d91884cd3300f3cb6836f4b7fdc5364e734b3 http://git.gnome.org/browse/glibmm/commit/?id=63cae37cd9dde19ffffe6d1b40c6bbb300f04a97 http://git.gnome.org/browse/glibmm/commit/?id=89a68889a0b35f011083f5d6ca5176672b1a9172
It's not terribly important, but I noticed that the new >> output-parameter feature doesn't work with Something* parameters (rather than the Something** parameters here). For instance, if I try: #m4 _INITIALIZATION(`Gdk::Rectangle&',`GdkRectangle', `$3 = Glib::wrap(&($4))') _WRAP_METHOD(bool get_cell_rect(const TreeModel::Path& path, const CellRenderer& cell{?}, Gdk::Rectangle& rect{.>>}) const, gtk_icon_view_get_cell_rect) Then the compilation fails because of this generated line: GdkRectangle g_rect = 0;
I think the following commit in glibmm should fix this: http://git.gnome.org/browse/glibmm/commit/?id=e06484cfd320798bad86ae4363242dab4d7d644a I'm assuming initializing the C object is wise so I use an assignment to a "default constructed" object to initialize the C object.
I think this bug is fixed so closing.