You don't have to use a different API in the unconfined process: just do
something like
for (const QString &applicationId: supportedClients) {
OnlineAccounts::Manager manager(applicationId);
auto accounts = manager.availableAccounts();
for (Account *account, accounts) {
... do stuff ...
}
}
The API can (and has been designed to) be used by unconfined clients,
but always under the assumption that the unconfined client is acting on
behalf of a proper click application, with its own ID and .application
and .service files generated by the click hooks.
Now, I've given another quick review at the D-Bus API and at your MP,
and I couldn't find any place that would break with your patch. The
assumption that one click application/scope cannot use more than one
service for the same account still holds, but that's enforced by the new
click hooks, while the service and library can -- at first sight -- deal
with multiple services, if your patch is applied.
Of course, given that I've kept that assumption in mind while writing
the project, it's likely that there might be other places which break,
and that your test case didn't uncover. It's for this reason that I'm
hesitant to accept this.
So, my suggestion is to go with the pseudo code above. If for some
reason that's not suitable (please explain), I'm ready to accept your
patch, provided that it's landed in a single silo along with your
project (so that we have a better confidence that this is the only
needed changed, and that there aren't hidden dragons).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1602159
Title:
Manager class only provides access to one (random?) service ID for an
account
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/online-accounts-api/+bug/1602159/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
