| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The CM can now refuse FinishInitialCandidates if it doesn't haven the candidates
it needs.
|
| |
|
| |
|
| |
|
|
|
|
| |
Also add DTMF unit test that covers both cases
|
|
|
|
|
| |
To make it work, example CM needs to create an Endpoint and we
have to wait for it to be connected to get to ACTIVE state.
|
|
|
|
|
| |
Keeping a ref on the stream for the timeout make it survive its TpBaseCallChannel
leading to issues later.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
examples/cm/callable/conn.c
examples/cm/callable/connection-manager.c
examples/cm/callable/media-channel.c
examples/cm/callable/media-manager.c
examples/cm/callable/media-stream.c
examples/cm/callable/protocol.c
examples/future/call-cm/call-channel.c
examples/future/call-cm/call-content.c
examples/future/call-cm/call-stream.c
extensions/call-content.c
extensions/call-stream.c
extensions/extensions-cli.c
tests/dbus/call-example.c
tests/dbus/callable-example.c
|
| | |
|
| |
| |
| |
| | |
We need GValueArray for dbus-glib, and it got deprecated in GLib 2.31.x
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If we emit Succeeded or Failed quickly enough after setting up the
TpProxy, the match rules might not have reached the dbus-daemon yet.
(The real ChannelRequest implementation avoids this bug by having the
Proceed method.)
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If if a new contact fetch is queued from the callback of last
contact fetch, it leads to a crash. This is because when queueing
the new item it is processed right away since it is the only item
in queue, then when it returns from g_simple_async_result_complete()
it calls process_contacts_queue() again so the item is prepared twice,
and then freed twice.
Fix this by keeping currently being processes item outside the queue.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If we emit Succeeded or Failed quickly enough after setting up the
TpProxy, the match rules might not have reached the dbus-daemon yet.
(The real ChannelRequest implementation avoids this bug by having the
Proceed method.)
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I thought I'd tested this... but apparently not.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Xavier Claessens <xclaesse@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45459
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This one is allowed to fail, so use tp_connection_disconnect_async()
directly.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45459
|
| | |
| | |
| | |
| | |
| | |
| | | |
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45459
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This calls Disconnect(), runs the main loop and asserts that it worked.
This can be used to supersede most calls to
tp_cli_connection_run_disconnect(), which is going away in Telepathy 1.0.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45459
|
| | |
| | |
| | |
| | |
| | |
| | | |
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45459
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
tp_call_channel_send_tones_async() is helper API calling
tp_call_content_send_tones_async() on each of its contents supporting
the DTMF interfaces.
tp_call_content_send_tones_async() does the queuing of events
|
|\ \ \
| |/ / |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is what most UI would expect; they just care if we are connected, not if
SimplePresence is actually implemented by the underlying CM.
https://bugs.freedesktop.org/show_bug.cgi?id=45120
|
| | |
| | |
| | |
| | | |
https://bugs.freedesktop.org/show_bug.cgi?id=45120
|
| | |
| | |
| | |
| | | |
https://bugs.freedesktop.org/show_bug.cgi?id=45120
|
| | |
| | |
| | |
| | | |
https://bugs.freedesktop.org/show_bug.cgi?id=45120
|
| | |
| | |
| | |
| | |
| | | |
This was supposed to be the trivial test (accounts are not even used yet) but
I already found a bug. :)
|
| | |
| | |
| | |
| | | |
Usefull for tests wanting to run with a specific set of valid accounts.
|
| |\ \
| | |/ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
If no account is connected, doc says we should return
(TP_CONNECTION_PRESENCE_TYPE_OFFLINE, "offline", "") but we use to return
(TP_CONNECTION_PRESENCE_TYPE_OFFLINE, NULL, NULL)
|
| | |
| | |
| | |
| | | |
This is a workaround for glib bug #661546
|
| | |
| | |
| | |
| | |
| | |
| | | |
Connection is async now so we shouldn't assume any ordering.
https://bugs.freedesktop.org/show_bug.cgi?id=45173
|
| | |
| | |
| | |
| | |
| | |
| | | |
Call channel should go to pending hold state until all the streams are
no longer pending stop (the one that didn't failed). Also, the transition
from pending stop to started is impossible.
|
|\ \ \
| |/ / |
|