[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Akonadi-next and KAccounts
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2015-09-17 16:25:01
Message-ID: 20318947.MHEMkzJJoc () serenity
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


tl;dr ->

* we'd need to port it to Windows; this might be easy. it might not be.
* we'd still need to think of the dominant mobile ecosystems separately
* the current code and repository layout is very much oriented to Plasma's 
needs, so some work would need to be done to make it more generally re-usable 
for Akonadi

Thanks for the answers. We'll use this and do an evaluation of our options and 
come back to you (Christian is back next week ...) 

More detailed response from me follows below ->

On Thursday, September 17, 2015 11.00:57 Martin Klapetek wrote:
> On Thu, Sep 17, 2015 at 3:40 AM, Aaron J. Seigo <aseigo@kde.org> wrote:
> > What is the cross platform story? With -v, how does kaccounts work on:

> However, KAccounts is just a wrapper around libaccounts-qt (which itself is
> a wrapper around libaccounts-glib), I have no data on how libaccounts-glib
> itself is supported on different systems, but I would assume it works, so

We'd need to confirm as we can't operate on assumptions for what is a hard 
requirement of akonadi. Doing some Internet searches turns up that it is 
focused on Linux (and POSIX systems), so we'd probably be the first to take it 
to that platform.

> in the
> worst case, different UI(s) could be written on top. The current KCM could
> even be made in such way that it installs an embeddable widget which could
> be just shared by those other UIs.
> 
> On Android and iOS I think it should use the native Accounts thingy it has,
> I'm not sure/aware if libaccounts could be integrated with it and use it as
> a backend though. I don't think that Android and iOS usecases ever came
> up with libaccounts.

So we'd use KAccounts on Linux/POSIX systems, port it to Windows or else use 
something more native there, and then use the native APIs on the mobile 
systems. Sounds like we'd require some sort abstraction, or else have a *lot* 
of duplicate code (not really an option). Given that KAccounts is very focused 
on UI interaction, I'm not really sure how we'd do that ...

> The Accounts stack is just about storing the account settings and
> credentials.

OK .. I thought originally one concept was to keep as much of the account 
information out of the hands of applications, but this is fine and would 
indeed work for Akonadi.

> > Why are there providers (e.g. owncloud, carddav, google-contacts-sync or
> > kioservice) in the integration repository rather than in the providers
> > repository? Why are all of those services other than owncloud in the
> > daemon
> > itself rather than implemented as a provider?[3]
> 
> Those are actually a kded module plugins, which is KAccounts-only daemon
[..]
> daemons
> doing things on those four events.

Let me rephrase then ... why is the code for these things bundled with the 
daemon itself? (The KIO stuff is actually built right in .. not even a 
plugin..)

> This repo separation is from historic reasons (2011 or so) when afiestas was
> working on it. Maybe it doesn't make sense anymore and these should be
> merged.

For Akonadi it would be nice to have just the functionality in the integration 
repo and all the provider code elsewhere ...

> > Why is the config UI, as created in KAccountsUiPlugin expected to create a
> > top-level dialog? Why is not a root widget (preferably sth QML) fetched
> > and
> > then the calling application create that dialog (or embed it somewhere in
> > its
> > UI)?
> 
> This is because the first user of KAccounts(5) was KDE Telepathy. KTp
> already has
> its config UIs in a self contained dialog. There was no feedback on that
> from anyone
> so it stayed like that.

OK...

> I don't see that as a big problem though. This way
> the plugins
> have much more freedom and flexibility with their UIs.

Generally, that's the opposite of what one wants for a system that should be 
as consistent as possible ... 

> > Is it possible to start account creation without the use of a KCM?
> 
> Yes, have a look at the src/jobs/createaccount.cpp. All it needs is to know
> which provider
> (which account) it is creating. That job is currently tied a bit to the
> KCM, but can
> be fixed/improved.

So currently no, but this could be done with some work in KAccounts.

> > Can account creation for a specific type of service be initiated
> > programatically? (versus the user taking action by, e.g., going into the
> > control center and opening an accounts kcm, then selecting the desired
> > service)
> 
> Yeah, you can just query libaccounts for a service type (eg. "IM"), see
> which providers
> contain that service, then just pick one and do what createaccount.cpp
> does. No clicking
> needed.

What I was trying to ask was "can the appropriate KAccounts UI for a given 
sort of account be created and shown by an application?"

As for entirely automated setup, there's not much point to using KAccounts if 
we have to go down to libaccounts at times as well; do you think fully-
automated setup could be reasonably added to  / implemented in KAccounts?

> It's currently the way it is because it works for all interested parties,
> but not set in stone.

Cool.

> The Google contacts sync is again meant for Plasma Mobile, where there is

Which makes me wonder again why it isn't elsewhere then :)

> no Akonadi
> but I'm expecting that Akonadi-next will get used on the Mobile and that
> the eventual
> Google resource will make this google-sync obsolete.

Perhaps / probably...

-- 
Aaron J. Seigo
["signature.asc" (application/pgp-signature)]
[Attachment #6 (text/plain)]

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]