| Summary: | Add an option to compile Akregator without Akonadi | ||
|---|---|---|---|
| Product: | [Applications] akregator | Reporter: | Woodsman <darrella> |
| Component: | akonadi-port | Assignee: | Frank Osterfeld <osterfeld> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | kamikazow |
| Priority: | NOR | ||
| Version First Reported In: | 4.10.1 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Other | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Woodsman
2013-03-29 23:57:03 UTC
Akregator never used KResources but its own storage backend interface. Maintaining both that and an Akonadi version in the same code base isn't really feasible - the code uses Akonadi::Item and Akonadi::Collection directly, and I don't see another abstraction layer justified. Not to mention that the current backend has severe issues: It causes crashes regularly, huge memory consumption and large startup times when having many items. Thanks for replying and explaining. :) I'm not a large scale user and I never see crashes or buggy behavior, although I do understand. My hope is for small scale users who enjoy KDE that somehow Akonadi can be disabled or neutralized. I appreciate what Akonadi can do for certain types of users, but small scale users are not part of that group. I fear the result is such users will abandon kdepim altogether. I'm in that group. I don't use Akonadi but I have used KMail, KAlarm, and Akregator for a long time. When the Akregator Akonadi changes are merged into trunk I'll have to find alternatives, much like the other PIM apps. That makes me sad. Thanks for a nice app through the years. :) (In reply to Frank Osterfeld from comment #1) > Akregator never used KResources but its own storage backend interface. > Maintaining both that and an Akonadi version in the same code base isn't > really feasible So, WONTFIX, right? |