If we know the expected interface (e.g. :g-interface-info is set),
then we always warned when calling a method on a different
interface. Don't do that, there's no way the expected interface can
know anything about this method.
Signed-off-by: David Zeuthen <davidz@redhat.com>
The GType for a GVariant is now a fundamental GType instead of a boxed
one so use the right marshaller.
Signed-off-by: David Zeuthen <davidz@redhat.com>
When asynchronously acquiring the DBus connection, assume a reference to
the proxy object, to avoid destroying it in the middle of the operation.
See https://bugzilla.gnome.org/show_bug.cgi?id=621905
Allow constructing a GDBusProxy for well-known names as discussed here
http://mail.gnome.org/archives/gtk-devel-list/2009-October/msg00075.html
including test cases.
Make it possible to create a GDBusProxy for a GBusType instead of a
GDBusConnection. This requires G_BUS_TYPE_NONE so add that too.
Nuke g_bus_watch_proxy() since one can now more or less use GDBusProxy
for this.
Port gdbus-example-watch-proxy to this new API and include this
example in the GDBusProxy doc page.
Also nuke the GType parameter from the GDBusProxy constructors as
requested here: https://bugzilla.gnome.org/show_bug.cgi?id=621229
Also update the porting guide and other API docs for this change.
Also fix a bug in the signal dispatching code so each subscriber only
get notified once, not N times, for the same signal. Also add a test
case for this.
https://bugzilla.gnome.org/show_bug.cgi?id=621213
Signed-off-by: David Zeuthen <davidz@redhat.com>
Fix proxy construction for objects with no properties in the case
where G_DBUS_PROXY_FLAGS_DO_NOT_LOAD_PROPERTIES isn't set.
The unfortunate side-effect here is that GDBusProxy can no longer be
used to test for "object existence", e.g. creating a GDBusProxy for
any path and interface will not fail. But that's not really a big
deal, if apps rely on that they are doing something very wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=621119
Signed-off-by: David Zeuthen <davidz@redhat.com>
This allows the caller to specify the reply type that they are expecting
for this call. If the reply comes back with the wrong type, GDBus will
generate an appropriate error internally.
- add a GVariantType * argument to g_dbus_connection_call() and
_call_sync().
- move the internal API for computing message types from introspection
data to be based on GVariantType instead of strings. Update users
of this code.
- have GDBusProxy pass this calculated GVariantType into
g_dbus_connection_call(). Remove the checks done in GDBusProxy.
- Update other users of the code (test cases, gdbus-tool, GSettings
tool, etc). In some cases, remove redundant checks; in some other
cases, we are fixing bugs because no checking was done where it
should have been.
Closes bug #619391.
There's no need to re-build the a{sv} array, just get it right out of
the parameters. Also avoid some string copies.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This makes it possible to use the cached properties mechanism even if
constructing the proxy with the DO_NOT_LOAD_PROPERTIES flag.
This is useful for cases where you obtain the and track object
properties out-of-band. For example, in udisks, the plan is to have
something like this
Manager.GetObjects (out ao paths, out aa{sa{sv}} all_properties);
Manager.ObjectAdded (o path, a{sa{sv}} all_properties);
Manager.ObjectChanged (o path, a{sa{sv}} all_properties);
Manager.ObjectRemoved (o path, a{sa{sv}} all_properties);
E.g. the first GetObjects() call will return *all* data about *all*
exported objects. Further, this way a client will only need to listen
these three signals (three AddMatch) on the Manager object and it will
never need to do GetAll() etc (e.g. can use DO_NOT_LOAD_PROPERTIES).
(Of course this only works if the client is interested in all
objects... while this is true for udisks it is generally not true for
other D-Bus services).
Also use expected_interface to check for programming errors.
Lots of people been suggesting this. We still use MethodInvocation /
method_invocation for handling incoming method calls so use call()
instead of invoke_method() helps to separate the client and server
facilities. Which is a good thing(tm).
Things compile and the test-suite passes. Still need to hook up
gio.symbols and docs. There are still a bunch of TODOs left in the
sources that needs to be addressed.
Signed-off-by: David Zeuthen <davidz@redhat.com>
