Age | Commit message (Collapse) | Author | Files | Lines |
|
Conflicts:
src/mcd-account.c
|
|
The McdAccount object may still be alive for a short while because of pending
async operations. We want to get rid of the D-Bus object as soon as possible
and so, for example, a new Account object replacing the deleted one can be
created.
Fix https://bugs.freedesktop.org/show_bug.cgi?id=79827
|
|
It's more useful when reading logs than G_STRLOC and that's what we already
use in src/mcd-debug.h
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=79832
|
|
Otherwise, holds_setup_lock is sometimes initially nonzero, making
us think we have the setup lock when really we don't, and leading
to an assertion failure when we try to release it.
For some reason I could only reproduce this during distcheck...
Reviewed-by: Xavier Claessens
(cherry picked from commit 6a073b02dbfda060142f7d47426fec55c7caba0d)
|
|
See:
https://wiki.gnome.org/action/show/Initiatives/GnomeGoals/InstalledTests
https://en.wikipedia.org/wiki/Test_Anything_Protocol
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74626
Reviewed-by: Guillaume Desmottes
|
|
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74581
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
This lets us get rid of the "ready" vfunc on plugins: we now
connect to each plugin's signals only after we have called
mcp_account_storage_list(), so we won't get double-notification for
accounts that are both present in the initial list and signalled.
This means we can remove a queue of delayed signal emissions from the
test D-Bus plugin (and when it's ported to this API, from Empathy's
libaccounts/UOA plugin). As far as I can see, list() and ready() happen
within the same main-loop iteration anyway, so I don't think it was
even possible to receive notification of a new account in that window.
Empathy's GNOME Online Accounts plugin never really implemented this:
in theory, it was incorrect, since any account that happened to be
added between list() and ready() would be lost altogether. However,
list() and ready() seem to happen in the same main-loop iteration,
so this might never have been a practical concern.
Rather than "fixing" Empathy's GOA plugin, it seems better to remove
the difficult case altogether.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74581
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
Previously, we'd only wait for accounts added in mcd_storage_load()
to become ready.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74581
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74581
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
If we're opportunistically migrating parameters according to
CM-specified types, we need to cope with uint16 ('q') for port numbers.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71093
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
mcp_account_storage_get_parameter() doesn't raise a GError.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71093
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71093
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
[also depend on new tp-glib for
tp_connection_manager_param_dup_variant_type -smcv]
|
|
It is not valid to call _mcd_account_connection_begin() unless the
account has a TpProtocol; in particular, if the account is "valid",
then we know it does have a TpProtocol.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71093
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
Now that I've deleted ExternalAccountStorage support, we have two
uses for this function:
* get the parameters to be passed to RequestConnection
* get the parameters for our own D-Bus API (PropertiesChanged,
GetAll, etc.)
For the former, we should know the types already, because we should
already have a concrete CM/protocol in mind by the time we get here.
For the latter, ideally we shouldn't need the CM's types at all: if
the backend is storing parameters with types, it's arguably more
correct for Parameters to contain what the user stored, even if that
isn't an exact match for what the CM wants.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71093
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
The initial flag is STORES_TYPES, which can be used to decide whether
to try to attach types to untyped parameters. Of our built-in plugins,
the default keyfile/variant-file storage and the D-Bus test plugin
have STORES_TYPES, but the "diversion" plugin does not.
Flags are account-specific in case they ever need to vary per-account
(e.g. a FROM_TELEPATHY_0 flag might be one way to deal with migration
from Telepathy 0.x to 1.0).
Also add some convenience API (has_all_flags, has_any_flag) to make
code that uses these flags easier to understand.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71093
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71093
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
Conflicts:
src/Makefile.am
|
|
As with telepathy-glib commit 36c2a545c9, a rule like this:
_gen/x.c _gen/x.h: prerequisites
$(AM_V_GEN)x-generator
doesn't consider x.c and x.h together. Instead, it expands to two rules,
one to generate x.c and one to generate x.h, which happen to run the
same commands.
This means that in the worst case, you can end up running x-generator
twice in parallel, and they'll race with each other and overwrite or
delete each other's output.
Updated version of a patch from Ross Burton, taking into account that
we now generate a separate header for the gtk-doc. I use the gtk-doc
header as the one that "matters", because it's the last to be generated.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69446
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
There isn't actually anything in these functions that needs to be async.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71093
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71093
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
There's hardly anything there any more anyway.
Take the opportunity to replace _mcd_account_set_connection_context
and _mcd_account_get_connection_context with simple access to the
priv struct.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71093
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71093
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
We never call this function without a TpConnectionManagerParam readily
available - which is just as well, because it looks as though it would
crash if mcd_manager_get_protocol_param() failed.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71093
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69600
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33485
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=44512
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69600
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
As with telepathy-glib commit 36c2a545c9, a rule like this:
_gen/x.c _gen/x.h: prerequisites
$(AM_V_GEN)x-generator
doesn't consider x.c and x.h together. Instead, it expands to two rules,
one to generate x.c and one to generate x.h, which happen to run the
same commands.
This means that in the worst case, you can end up running x-generator
twice in parallel, and they'll race with each other and overwrite or
delete each other's output.
Updated version of a patch from Ross Burton, taking into account that
we now generate a separate header for the gtk-doc. I use the gtk-doc
header as the one that "matters", because it's the last to be generated.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69446
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
Reviewed-by: Xavier Claessens <xavier.claessens@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27727
|
|
|
|
|
|
|
|
Otherwise, it will reduce test coverage while porting to Telepathy 1.0:
all the tests dealing with old locations need to be disabled until we
implement 0.x -> 1.0 migration.
|
|
This test hasn't dealt with a keyring for a while, and now only covers
"variant files". Split it into two: one deals with creating an account
at runtime in the default backend, and one deals with loading files
from disk.
|
|
|
|
These are impossible to test without restarting Mission Control, because
we only read from one such location at a time; so there's no point in
trying to bundle them into one test.
|
|
|
|
We didn't release this in 5.15, so it'll be the 5.18 API instead.
|
|
As per Xavier's review, we don't need to call
mcd_account_get_unique_name(), because account unique names (object path
tails) are the keys in this map anyway.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27727
|
|
We usually don't pass const objects
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27727
|
|
I makes no sense now that MC stopped caring about secrets.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27727
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27727
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27727
|
|
In the process, inline mcd_account_manager_write_conf_async
and uncork_storage_plugins into their callers, with considerable
simplification because the async API isn't actually used any more.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27727
|
|
Nothing ever sets write_conf_id nonzero, so this can never be called
any more.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27727
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27727
|
|
We should always know what we're deleting, now.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27727
|
|
We shouldn't remove it from the hash table until the storage plugin
says ::deleted: until then, deletion could fail. This will become
significant when we start considering deletion of a deleted account to
be an error.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27727
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27727
|