Improve KDE PIM
Open, Needs TriagePublic

Description

Description

Every DE need to have good PIM applications set. KDE have many applications in that area (KDE PIM), but as a set is not well integrated and presented. First, there are many application with same/similar purpose. Second, I think whole set have confusing applications names. For example, every PIM usually have Calendar application, i don't know why KDE use KOrganizer, when peoples expect Calendar (Google Calendar, Apple Calendar, Microsoft Outlook Calendar, Thunderbird Calendar), why KDE dont have Calendar or Kalendar? Furthermore, communication set of applications is more confusing, KMail, KAddresBook, Kontact, Kube, Konversation... Naming a set of application Kontact is totally confusing(for me Kontact associate on address book). I know, that are tons of job doing in backend technologies for all applications(Akonadi), but I think it is time to make big polish in term of usability in frontend, as application suite. Presentation, integration, help system need to be better to be usable as a suit. If users need to replace only one application from set( for example, use Thunderbird instead KMail), that causes more problems. So, my suggestion is to work on usability and polishing KDE PIM suite.

What it will take

<What do we need to do to make this reality? What kind of support do you need?>

How we know we succeeded

<Will we have fluffy kittens? Anything we can measure? How will the world be better once we're done with this?

Relevant links

<any links that will help people find more information and understand the goal better>

I am willing to put work into this

I am interested

crozbo created this task.Jun 11 2019, 3:02 AM
crozbo updated the task description. (Show Details)Jun 11 2019, 9:23 AM
masonbee reopened this task as Open.
ngraham updated the task description. (Show Details)Jun 14 2019, 12:12 PM

It would be really great to extend the "online accounts" kcm and make the PIM software automatically use those accounts.
I really enjoyed this workflow in my GNOME days back then.
Or maybe combine them anyhow ?

lydia updated the task description. (Show Details)Jun 15 2019, 7:19 AM
lydia added a subscriber: dvratil.Jun 15 2019, 7:25 AM

Disclaimer: I'm speaking with my Akonadi+Kontact developer hat on (read: I can't speak for Kube/Sink, Konversation, Itinerary ...)

I think just saying "Improve KDE PIM" may be a too broad goal. There are many areas that need to be improved in order for Kontact to move forward, some more exciting, some less so, but the goal should IMO be more specific in this regards

I think there are several key areas that currently need more focus:

Account management

Boils down to:

  1. Smooth first user experience - an initial wizard to make account setup simple and fast and allow the user to tune Kontact to their liking
  2. Simpler account management - KMail has Identities + incoming accounts + outgoing accounts, then each other app has its own accounts (google calendar, etc.) - finding a way to simplify this into a "single-click" setup would be awesome, however it is necessary to preserve the flexibility currently offered by Identities (I believe some inspiration can be drawn from Thunderbird or K9)
  3. Integration with Online Accounts - this one might be much more complicated than it sounds, but indeed we would like to see this at some point - I believe that this should be a KDE-wide effort for all applications to use Online Accounts to avoid the confusing state when some apps do use it and some don't.

Mobile

Akonadi can be a great backend for mobile PIM apps, it needs some extra features ("sliding window" of keeping only messages from the last X weeks, ability to download emails without attachments, etc.) - most of this has the necessary infrastructure in place already, there's just code missing to implement those particular functionalities.

Building a tightly integrating mobile PIM suite with Kirigami on top of Akonadi and our libraries should then be fairly simple, and again help to demonstrate the versatility of our technologies.

Developer Story

Not a fun or easy topic - PIM carries around a lot of legacy code, often written in times where Qt or KDE did not yet have a necessary feature (e.g. font configuration) which is no longer needed and should be removed and replaced with whatever the current equivalent offered by Frameworks and Qt is. The dependency tree between all our repositories is more of a jungle than a tree with various hacks to break dependency loops. There's no really easy way for a newcomer to just come and fix a small big in KMail or KOrganizer, as the relevant code often lives in one of the libkdepim or libpimcommon or pimappslibs or whatever repositories.

We need to clean this mess up, we need to provide simple tooling and guides for newcomers to make fixing bugs and implementing new features as easy and straightforward as it is in Plasma.

Polish

There's a ton of details that could use polishing. As a daily user, I'm mostly immune to those by now but I understand how annoying those can be to new users. Identifying all those rough edges and fixing them might be a good start for beginning contributors or generally new PIM contributors, who don't dare to tackle complex issues spanning multiple components. I think that solving the developer story is an absolute prerequisite to this, however.


That's my insight as a dev what I perceive as the biggest pain points in PIM right now, of course, this is a good opportunity for the wider community to express where they would like Kontact (and KDE PIM in general) heading to in the future (cue the "kill Akonadi" rants 😉 ...)

ognarb updated the task description. (Show Details)Jun 17 2019, 10:33 AM
ognarb updated the task description. (Show Details)
ognarb added a subscriber: ognarb.

@dvratil

I think just saying "Improve KDE PIM" may be a too broad goal. There are many areas that need to be improved in order for Kontact to move forward, some more exciting, some less so, but the goal should IMO be more specific in this regards

I propose this, and i know it is broad goal, but I think the point of Golas, is to be major task, not specific minor problem. From my point of view, kde have great applications, and many are used outside kde, but KDE PIM is so confusing and unreliable, that it is rarely used from anybody, including kde community. I am just a kde user, and i think, if KDE wanna be competitive, current state of PIM is unacceptable.

Disclaimer: I'm speaking with my Akonadi+Kontact developer hat on (read: I can't speak for Kube/Sink, Konversation, Itinerary ...)

I see from your disclaimer, part of problems, currently the PIM suit is not well defined, there are many applications in kde ecosystem with same/similar functions, i see that as a fragmentation and confusing for users. IMO, KDE PIM need to be redesigned from frontend point of view, to be a proper application suit. Of course, to solve that a lot of work on backend is needed.

I am not involved in development, so maybe may opinions are wrong.

ognarb updated the task description. (Show Details)Jun 17 2019, 10:38 AM

the PIM suit is not well defined

I hope I'm not leaving anyone out, but this is basically what KDE PIM currently is:

KDE PIM -> project
Kontact -> product, PIM Suite (includes KMail, KOrganizer and friends)
Kube -> product, PIM Suite
Zanshin -> PIM application, task manager
Itinerary - PIM application, trip planner (oversimplified)
Trojita - PIM application, IMAP email client

Generally speaking, to most people KDE PIM == Kontact, but we now have more projects under the PIM umbrella, projects that cannot or don't want to necessarily be unified (e.g. Kontact and Kube), so it's important to differentiate this. And I think it's perfectly fine to have two PIM suites for instance, same as it is OK to have multiple media players, file managers or text editors - each targets a different audience, each has its pros and cons.

I am not involved in development, so maybe may opinions are wrong.

Your opinions are very much welcomed, feedback from users is important to us.

Yea, it is good to have many applications, but that can confusing for general public, they wanna one tool that work, they don't care about minor/backend differences. IMHO, kde need promote and make KDE PIM as a first class kde applicatons, like Dolphin, Konsole or Kdenlive, Krita. For example, most of the linux distributions who ship Plasma, normally ship Dolphin, Konsole, Okular, but who ship Kmail, usually they ship Thunderbird. I know, it is not best example to compare file manager, with email client, but it is on the way what i wanna say. I think that kde ecosystem, or generaly linux/floss ecosystem need to improve in PIM niche, to be competitive against others OS. Maybe, the biggest problem with PIM is that most of users going full online(Gmail, GoogleDocuments, ChromeOS, Microsoft Office online), mobile usage come before native computer applications. How to position KDE PIM, is hard question, and harder to achieve success. But, it is clear that KDE PIM need improvements.

jrioux added a subscriber: jrioux.Jun 21 2019, 3:06 AM

Wow, I didn't know about KDE PIM, thanks for the description @dvratil !
@crozbo I agree that some renaming could be used to get more in line with the expectations of the market.

At first, didn't know that PIM = personal information management

I like that there is a distinction between identity and account. As my professional identity is not the same as my keyboard warrior identity. It should be distinct and I would like to be able to manage them easily in kde.

I do believe that KDE should rework the PIM. It's important that the code is cleaned and easily maintainable as it can be of large consequences if there is a security bug/exploit. It may be a major obstacle for T11080.

At some point, I am wondering why we don't just integrate kde to thunderbird instead of maintaining kmail ? If there is already a good opensource application out there, then why not just kde-ized it ? Microsoft just did that with Edge... we will see how it turns out in a few years.

@dvratil I'd like to add on account management as I think it's fairly important :

All online accounts should be managed in *System Settings->Online Accounts* and individual applications should ask permission to access those accounts. Strict control should be in place in respect of *privacy* and it should be possible to see when an application requested an online account. Individual applications should not cache or save credentials and request them each time.

  • Change a password only once for all applications using the same account
  • Rights could be revoked from *System Settings* for an application
  • Temporary disabling an account should be possible
  • Less possibility of leaking credential due to application bug/exploit
  • Guaranty secure storage of credentials
jrioux added a comment.EditedJun 21 2019, 3:33 AM

While thinking about security, I just checked CVE details for KDE.

While comparing KMail to Thunderbird, the difference in numbers of CVE is huge. Is KMail better or just less tested for vulnerability than Thunderbird ?

With all the security concerns of today, is it worth it for KDE to develop it's set of PIM tools or would it be better off by pooling the efforts with major players ?

@jrioux Renaming anything is controversial task, and it is hard to have consensus how solve it, because renaming in start make users more confusing, but in long term can be correct. My suggestion is to rename KOrganizer to Kalendar, but I am not sure that everybody agree with my suggestion. And in the end, application name is important, but functionality is more important, renaming is waste of energy and time.

Yes, Thunderbird is most known email client in FLOSS/linux community and it will be nice to kde-izing it, but that is extremely hard/impossible if it is third party application, best way will be to incubate Thunderbird to KDE(same, extremely hard/impossible).

Online account management and integration are most crucial features where KDE PIM need to improve.

jrioux added a comment.EditedJun 21 2019, 4:12 AM

By kde-izing, I mean that it could be possible to do it partially. Like writing a module to access KDE account/identity api. I don't see the value to rewrite all UI components to Qt, but some parts can check if running in KDE and access certain features. I do like plasma-browser-integration, so it could work both way.

Also, there are some more critical applications that must provide a certain level of security and unbreakability. If KDE can't maintain those, it should think in a creative way.

lydia added a subscriber: lydia.Jul 19 2019, 10:30 AM

I think the proposal is still focused a bit too much on the specific solution. What do we want to achieve? What story do we want to be able to tell? How is the world going to be better?

lydia added a comment.Sat, Aug 3, 4:04 PM

Are you going to flesh out the description more based on the comments so we can take it into account for the voting? When ready please move it to the ready for voting column.

lydia assigned this task to crozbo.Sat, Aug 3, 4:08 PM
lydia added a comment.Tue, Aug 13, 8:51 PM

Quick reminder that there are two days left before the voting starts. Please make any changes you still want to make soon and let's move it to the ready for voting column.