On Wed, Oct 19, 2016 at 10:54 AM, Elvis Angelaccio <elvis.angelac...@kde.org> wrote: > On Wed, Oct 19, 2016 at 5:17 AM, Martin Klapetek > <martin.klape...@gmail.com> wrote: >> On Mon, Oct 17, 2016 at 12:54 PM, Jonathan Riddell <j...@jriddell.org> wrote: >>> >>> <Sho_> * Services integration - I see more and more users who have >>> data locked up in clouds (GDrive, etc.) and rely on accessing it >>> <Sho_> Gnome has GDrive integration, we need to do more on getting >>> cloud filesystems into our software too, but we dropped the ball on >>> KAccounts etc. for now >> >> >> As the former KAccounts maintainer, I'd like to share some insights on this. >> >> The tech is there. It's proven by real world usage in Ubuntu (incl. Phone), >> Meego before that (iirc) and to some extent also Gnome, which has its own >> fork of the same thing (I guess they just really don't like Qt anywhere). >> Also >> Elementary is using one of these, but I don't remember which. And if I'm >> not mistaken, also Jolla in their phones. >> >> So we have the tech, but what we're missing are two things, really. >> >> 1) Things actually using it. We've had KAccounts for a while but there was >> nothing taking advantage of it, except KDE Telepathy, which migrated fully >> to it. So it sort of became a synonym for KTp accounts config. On the other >> hand, there was nothing much else that would actually need it. There was >> an OwnCloud lib or Plasma thingy at some point where I pleaded to have the >> account setup done through (K)Accounts to boost the adoption, but it never >> happened. Related to that is... >> >> 2) Buy in from PIM. I mean, let's face it, the real accounts user in the >> system >> is PIM, with all the emails and calendars and contacts and what not. This >> obviously requires quite some large effort to actually migrate everything to >> it and sadly the PIM team is long time understaffed. Now with the new Sink >> thing, this could have been a chance, but, again, after asking couple times >> about the accounts plan, (K)Accounts was never in the picture. And that's >> a problem. >> >> And so now we have this system that nobody in/around KDE wants to use. >> My take on it is that people (devs) don't really understand how that system >> works and how to take advantage of it, which is partly my fault. It is >> fairly >> complex system on the inside with lots of points of possible breakages, but >> also allows for great flexibility all around. >> >> So, imho, in order to successfully follow literally every other desktop >> these >> days, it needs a proper full integration in all things using accounts. And >> it really >> shouldn't be just an afterthought. It needs to be put right at the core of >> those >> things and workflows should be redesigned to take that into account (heh). >> It >> needs to be a conscious community-wide effort, like Frameworks was. >> Otherwise >> KAccounts will stay exactly where it is now - a promising (egg-)shell that >> has no >> real use. >> >> Unfortunately if the past two years are any indication, especially with >> Sink, >> the road ahead is not very bright. >> >> I'm happy to try my best to answer any possible future questions about the >> system >> you might have. Friedrich Kossebau was also writing a tutorial about it at >> some >> point, but I'm not sure where it ended up (if at all; I also failed to >> follow up on that). > > > Hi Martin, > I'm planning to integrate KAccounts with kio-gdrive, so your email is > very much appreciated. > What exactly is "Kaccounts" in the first place? Are we talking about > the kaccounts-integration repo? > A tutorial would be great, but maybe is enough to look at the KDE > Telepathy usage. Could you share more details about this?
Purpose Youtube integration is using it [1]. You can easily use the GetCredentialsJob for these things, or directly use AccountsSSO for less dependencies. Aleix [1] https://quickgit.kde.org/?p=purpose.git&a=blob&h=b0d08c489965a330dd140590856a7d802f5efaea&hb=a7be97ffd5610a27360eedf2938efc8be04ff5f4&f=src%2Fplugins%2Fyoutube%2Fyoutubejobcomposite.cpp
