--===============5376354670791923869== Content-Type: multipart/signed; boundary="nextPart1663820.GheE11VEOq"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart1663820.GheE11VEOq Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" 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 Plasm= a's=20 needs, so some work would need to be done to make it more generally re-= usable=20 for Akonadi Thanks for the answers. We'll use this and do an evaluation of our opti= ons and=20 come back to you (Christian is back next week ...)=20 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 wrot= e: > > What is the cross platform story? With -v, how does kaccounts work = on: > However, KAccounts is just a wrapper around libaccounts-qt (which its= elf is > a wrapper around libaccounts-glib), I have no data on how libaccounts= =2Dglib > 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 h= ard=20 requirement of akonadi. Doing some Internet searches turns up that it i= s=20 focused on Linux (and POSIX systems), so we'd probably be the first to = take it=20 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. >=20 > On Android and iOS I think it should use the native Accounts thingy i= t 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 ca= me > up with libaccounts. So we'd use KAccounts on Linux/POSIX systems, port it to Windows or els= e use=20 something more native there, and then use the native APIs on the mobile= =20 systems. Sounds like we'd require some sort abstraction, or else have a= *lot*=20 of duplicate code (not really an option). Given that KAccounts is very = focused=20 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 accou= nt=20 information out of the hands of applications, but this is fine and woul= d=20 indeed work for Akonadi. > > Why are there providers (e.g. owncloud, carddav, google-contacts-sy= nc or > > kioservice) in the integration repository rather than in the provid= ers > > repository? Why are all of those services other than owncloud in th= e > > daemon > > itself rather than implemented as a provider?[3] >=20 > Those are actually a kded module plugins, which is KAccounts-only dae= mon [..] > daemons > doing things on those four events. Let me rephrase then ... why is the code for these things bundled with = the=20 daemon itself? (The KIO stuff is actually built right in .. not even a=20= plugin..) > This repo separation is from historic reasons (2011 or so) when afies= tas was > working on it. Maybe it doesn't make sense anymore and these should b= e > merged. For Akonadi it would be nice to have just the functionality in the inte= gration=20 repo and all the provider code elsewhere ... > > Why is the config UI, as created in KAccountsUiPlugin expected to c= reate a > > top-level dialog? Why is not a root widget (preferably sth QML) fet= ched > > and > > then the calling application create that dialog (or embed it somewh= ere in > > its > > UI)? >=20 > 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 t= hat > 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 shou= ld be=20 as consistent as possible ...=20 > > Is it possible to start account creation without the use of a KCM? >=20 > Yes, have a look at the src/jobs/createaccount.cpp. All it needs is t= o know > which provider > (which account) it is creating. That job is currently tied a bit to t= he > 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 int= o the > > control center and opening an accounts kcm, then selecting the desi= red > > service) >=20 > Yeah, you can just query libaccounts for a service type (eg. "IM"), s= ee > which providers > contain that service, then just pick one and do what createaccount.cp= p > does. No clicking > needed. What I was trying to ask was "can the appropriate KAccounts UI for a gi= ven=20 sort of account be created and shown by an application?" As for entirely automated setup, there's not much point to using KAccou= nts if=20 we have to go down to libaccounts at times as well; do you think fully-= automated setup could be reasonably added to / implemented in KAccount= s? > It's currently the way it is because it works for all interested part= ies, > but not set in stone. Cool. > The Google contacts sync is again meant for Plasma Mobile, where ther= e 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 t= hat > the eventual > Google resource will make this google-sync obsolete. Perhaps / probably... =2D-=20 Aaron J. Seigo --nextPart1663820.GheE11VEOq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlX66WAACgkQ1rcusafx20NxXQCfWaPG7YgPADH1XALeSV5+ScO2 Y34AoJg1Nygyky41GeQYFFMOvI0DScgx =VDYV -----END PGP SIGNATURE----- --nextPart1663820.GheE11VEOq-- --===============5376354670791923869== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KS0RFIFBJTSBt YWlsaW5nIGxpc3Qga2RlLXBpbUBrZGUub3JnCmh0dHBzOi8vbWFpbC5rZGUub3JnL21haWxtYW4v bGlzdGluZm8va2RlLXBpbQpLREUgUElNIGhvbWUgcGFnZSBhdCBodHRwOi8vcGltLmtkZS5vcmcv --===============5376354670791923869==--