| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
New transfer and naming policy has been discussed in
https://bugs.freedesktop.org/show_bug.cgi?id=39189 and is
documented there: http://telepathy.freedesktop.org/wiki/Style/TelepathyGLib
_tp_channel_get_immutable_properties() is kept internal because we don't
want to expose more dbus-glib structures. tp_channel_dup_immutable_properties()
is added, it returns a GVariant and should be needed only to TpChannel
subclasses.
|
|
|
|
|
|
| |
Those proxies should be constructed using TpSimpleClientFactory
https://bugs.freedesktop.org/show_bug.cgi?id=49372
|
| |
|
|
|
|
|
|
|
| |
API on TpChannel is now deprecated but still used to implement
the corresponding API on TpTextChannel.
https://bugs.freedesktop.org/show_bug.cgi?id=49215
|
|
|
|
|
|
| |
This is now consistent with channel_destroy_cb() for example.
The idea is if there is an error, but channel is invalidated
anyway, there is no point in fallback to Close.
|
|
|
|
| |
We deprecated this in 0.11.
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=49213
|
|
|
|
|
|
|
|
|
|
|
|
| |
GAsyncResult guarantees to call your callback from the main loop.
For historical reasons (basically "5 years ago I didn't know any
better"), TpProxy does not: if the interface is missing or the proxy
has been invalidated, the callback is called re-entrantly. I'm going
to fix that in Telepathy 1.0, but for now, let's give GAsyncResult
the correct semantics.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45514
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
|
|
|
|
| |
It is not always a good idea for bindings to always rely on GObject::get_property(),
it can be slow to access properties that way everytime instead of keeping
a proxy object in native language.
|
| |
|
| |
|
|
|
|
|
|
| |
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45842
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=45842
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
|
|
|
|
|
|
| |
In contrast to the previous commit, I'm just using NULL here -
telepathy-glib has an explicit dependency on GLib 2.30.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46523
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
|
|
|
|
|
|
| |
Many didn't use this shorthand, and some even didn't declare one of the
three strings as static (causing GObject to copy it).
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Vivek Dasmohapatra <vivek@collabora.co.uk>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We still have multiple gtk-doc warnings which are much harder to fix,
such as things like this in the spec:
"see bug #26417"
html/telepathy-glib-channel-text.html:1538: warning: no link for: '26417:CAPS' -> (<span class="type">26417</span>).
and the change I made to the code generator in c0b13f7ccc26e78.
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
|
|
|
|
|
|
|
|
|
|
| |
tp-glib uses to rely on its introspection queue to add the interface ID
of its channel type even when the type was already known during
construction (which is basically alway the case now as we always pass the
immutable properties when creating a TpChannel).
This was forcing TpChannel subclasses to have a CORE feature to connect
signals on their channel type interface for no good reason.
https://bugs.freedesktop.org/show_bug.cgi?id=41729
|
| |
|
|
|
|
|
| |
It ensures that all TpContact objects related to a channel are prepared
with factory features. It fail to prepare on old CMs.
|
| |
|
| |
|
|
|
|
|
|
| |
This is a new object replacing TpBasicProxyFactory but can construct
any known TpProxy subclasses, guarantee their uniqueness per object-path
and keep a user-defined set of features to prepare on them.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
There is already a check at the beginning of the function preventing that.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
callback
|
|
|
|
|
|
|
|
|
|
| |
tp_cli callbacks don't guarantee not to call the callback re-entrantly:
if the interface is absent, or the proxy has been invalidated, they'll
call the callback before returning. Sad times.
Also document why channel_remove_self_cb doesn't have to do this: it's
only called after preparing the GROUP feature, which does guarantee to
be idle.
|
|
|
|
| |
This is consistent with what we do for RemoveMembersWithReason.
|
|
|
|
|
| |
If we add proxy mode to Idle (Bug #24273) we'll need to distinguish
between the two actions.
|
|
|
|
|
| |
On second thoughts, we do need to distinguish between closing a channel,
and leaving it.
|
| |
|
| |
|
| |
|
|
|
|
| |
ISO C forbids them, and they're an easy thing to get rid of.
|
| |
|