I’ve been baffled why KDE has so many different places for configuring online accounts. Every KDE PIM app comes with its own slightly different UI where you can set up Akonadi resources. The underlying set of resources is the same, but they are shown in different ways. There seems to be no discoverable place where I can manage them all in a single location. When people create a new app, like the Merkuro developers did, they create their separate new configuration UI, again for managing the same set of Akonadi resources.
Then there’s the Online Accounts KCM, where I can configure a totally different set of resources. It’s not obvious in what way they are different — they seem to be more about file sharing (?). But I can configure a Google account there, and it asks me for access to my calendar, except that the resource is usable only for uploading videos to Youtube, and even though I’ve given it access to my calendar, I can’t actually use it to access my calendar
Wouldn’t it be better if there was a single KCM for managing all online accounts (filesharing, PIM or otherwise)? Or at least a dedicated KCM for online PIM accounts so that I can manage them through System Settings? To me that would make more sense, as these online resources that are shared across different apps. And then the developers of a new app wouldn’t have to come up with their own account setup UI. Instead they could just stick to the specifics — selecting specific calendars (in a calendar app), configuring mail sending behaviour (in a mail app) and so on.
Is this really an issue worth solving? Online accounts (internally named KAccounts) are a completely different system from Akonadi’s (KDE PIM). Yes it’s not clear what the difference is to the end user, but I’m not sure of a good solution for that.
It’s possible that these applications can be used outside of KDE, so it would still need some way to configure it inside of these applications anyway. Arguably the most important function of account management (the setup wizards and dialogs) are already shared across all Akonadi apps.
Yeah, ideally these apps could pull their account information from KAccounts so you could configure your accounts once in a central location.
I’m looking at this from the user’s point of view, based on real confusion that I had when trying to do more work with KDE PIM. This confusion is a real problem that is IMHO worth solving.
Users work with a range of services online. They interact with them through their account. They shouldn’t have to develop a technical understanding that KAccounts and KDE PIM resources are different systems that do different things. At least the UI design could guide them better.
(A separate issue: it doesn’t help when both systems have parallel implementations for managing login tokens that don’t talk to each other — like with Google, where users have to give account permissions twice, to KAccounts and to Akonadi.)
Arguably the most important function of account management (the setup wizards and dialogs) are already shared across all Akonadi apps.
Kind of, each new app comes with a new account configuration window with its own new bugs. For example when you set up a Google account in Merkuro, it’s initially unusable: Akonadi doesn’t pick up the new configuration and you’re stuck with an account that says “configured account does not exist” (473897 – Cannot add Google Groupware, "Configured account does not exist" then "Resource is not configured"). KOrganizer or KMail have a “Reload” button that will make Akonadi pick up the new account (it’s not logical from a user point of view why you should have to do click there, but that’s another, separate problem). Merkuro doesn’t have that, so when you want to set up a new Google account, you currently have to go through KOrganizer.
For a user it’s not obvious why you have to set up your account in a different app that you’re not going to use. I also get that KDE is not Plasma and that applications can be run standalone. But if a Plasma user would have a single place to manage these KDE PIM account configurations in a coherent way, that could help them.
The short and annoying answer: no-one had the time and interest to do it yet.
The short and annoying answer with a bit more historical trivia: KDE PIM code base is one of the oldest within KDE, there are many legacy pieces carried all the way back from KDE 2. It’s not so long ago that we removed font configuration from KMail. Why did KMail have a dedicated font configuration screen, you ask? Well because it was written before KDE had a central place to configure fonts globally! Why did we only remove it recently? No-one had the time and interest to do it before…same with dedicated “account” setup in each PIM app.
The answer with a gleam of hope: I would love to use KAccounts to set up IMAP, Google Calendar, EWS and what not from a single place instead of having gods-know-how-many “account management” screens (you haven’t found them all on your screenshot ;-)). Some 4 years ago I actually added support for KAccounts into Akonadi and implemented support for it into the Google resource. The commit even has a link to a youtube video: https://www.youtube.com/watch?v=7plCbvfQlA8 showcasing how it works (judging from the fact that the Google login screen is in Italian, I most likely did this during Akademy in Milan ). The reason why I did it for Google was that there was already Google account support for KAccounts, so I did not have to implemented any new UI for that.
So we are really not that far from actually achieving this and the biggest puzzle pieces that are missing are KAccounts plugins for basically all the services that KDE PIM supports (except for Google and Nextcloud (DAV)). This is where the work stopped. I remember looking into adding IMAP plugin and sort of losing interest of dealing with this side of things, as it required substantial effort at that time…
So, if anyone would be up to implementing KAccounts plugins for various online services, it would bring us very close to having a single place to manage online accounts. Alas, no-one had the time and interest to do it yet.