| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
It has a dbus-glib type, and by not using
tp_dbus_properties_mixin_getter_gobject_properties(), we can avoid it.
It is not used in Folks, Empathy, MC or the "big 5" CMs.
|
|
remove
They are not used in Folks, Empathy, MC or the "big 5" CMs, except for one
use of dbus-status in helper code for Folks' regression tests (which will
disappear when resynced from telepathy-glib).
|
|
tp_dbus_properties_mixin_getter_gobject_properties()
Using that tied us to having a GDBus property whose type matches the
dbus-glib type, which is API we don't want.
|
|
This used to be done so we could emulate a connection manager older
than telepathy-spec 0.19.2, but that functionality was removed in
commit 347307b7.
|
|
The timing requirements for test_change_inconveniently() are very
specific, and on my laptop, using the GDBus filter wasn't good enough
(probably because looping on g_main_context_iteration() runs a whole
iteration and cannot be stopped halfway through). I could usually
reproduce a test failure by running the telepathy-glib tests in
parallel with the telepathy-gabble tests.
|
|
MC still needs this.
|
|
GDBusConnection and TpSvcInterfaceSkeleton does it for us already.
|
|
We prevent TpSvcDBusProperties interface to be registered so
GDBusConnection will handle that itself using skeleton's vtable.
|
|
directly
We are about to stop exporting TpSvcDBusProperties iface so they
would be no-op.
|
|
We are about to stop exporting TpSvcDBusProperties iface so they
would be no-op.
|
|
We are about to stop exporting TpSvcDBusProperties iface so they
would be no-op.
|
|
We are about to stop exporting TpSvcDBusProperties iface so they
would be no-op.
|
|
We are about to stop exporting TpSvcDBusProperties iface so they
would be no-op.
|
|
|
|
|
|
They have a dbus-glib type, and Empathy exclusively uses
tp_text_channel_supports_message_type() instead.
|
|
|
|
|
|
|
|
|
|
|
|
It's still a GHashTable internally, because lots of subclasses still
rely on that.
|
|
We're using an Entity_Type_None (nameless chatroom) channel, but
claiming in its immutable properties that it has a non-empty
target of type Contact. That means we're effectively making assertions
about whether the immutable properties we specified at the beginning,
or the result of GetAll(), will "win", which makes this test
unnecessarily brittle.
|
|
Implementing TpChannelIface meant that channel-type, handle-type
and handle had to be settable at construct-time. That is no longer
a supported thing to do: everyone should be using the immutable
properties dict.
|
|
|
|
The implementation is really simplistic, and copies everything into
dbus-glib data types.
|
|
Also be (somewhat) cancellable, while I'm there.
|
|
|
|
|
|
It uses the dbus-glib type system.
|
|
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=76369
|
|
The contact list mixin doesn't need channels any more.
|
|
|
|
Under GDBus, we can receive more than one signal in the same iteration
of the main loop. I missed this instance in my initial GDBus port
because it's inconsistent and hard to reproduce, but it's the same
anti-pattern: we're waiting for two signals that both happen as a
result of the same action:
signal_cb (...)
{
g_main_loop_quit (loop);
}
...
test (...)
{
...
g_main_loop_run (loop);
... things without side-effects ...
g_main_loop_run (loop);
...
}
I think it's better style for test code to be more explicit and have
less spooky-action-at-a-distance, anyway.
|
|
|
|
|
|
|
|
|
|
tp_dbus_g_method_return_not_implemented is non-essential, so we can
easily put it in the -dbus library.
tp_proxy_check_interface_by_id should be available in the high-level
API, but with a couple of #define hacks we can make it available to
generated code in the -dbus library under the same name.
tp_proxy_pending_call_v1_new and tp_proxy_signal_connection_v1_new
can safely go in the -dbus library: they don't deserve to be part of
the high-level API.
This reduces us to one shared library per level of API stability,
which is exactly the right number.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=76855
Reviewed-by: Xavier Claessens
|
|
Now that tp_dbus_g_method_return_not_implemented() uses
g_dbus_method_invocation_return_dbus_error() to avoid depending
on a particular GError, these don't have to be core.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=76855
Reviewed-by: Xavier Claessens
|
|
TpSvcInterfaceInfo encodes the assumption "we emit dbus-glib-style
signals" which we don't want to keep forever. If we confine them to the
-dbus library, it'll be easier to break its ABI.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=76855
Reviewed-by: Xavier Claessens
|
|
The Telepathy D-Bus API part (the exact details of how we encode
addresses) should go in the -dbus library; the GIO part should go
in the main library.
Use GIOError instead of TpError in the -dbus part, so TpError won't need to
stay in the core library.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=76855
Reviewed-by: Xavier Claessens
|
|
These functions should be useless in a post-dbus-glib environment.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=76855
Reviewed-by: Xavier Claessens
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=76855
Reviewed-by: Xavier Claessens
|
|
Replace a couple of tp_dbus_check_valid_object_path calls with
g_variant_is_object_path to avoid having to move the former
into the dbus or core library.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=76855
Reviewed-by: Xavier Claessens
|
|
This is basically only useful for the dbus-glib type system.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=76855
Reviewed-by: Xavier Claessens
|
|
|
|
|
