The current road map provides for converting Akregator to the Akonadi framework. Akonadi is useful to certain types of users, such as enterprise users and those who store personal information online. At the other end of the spectrum are users who have no such needs and use Akregator in a limited manner. Please provide cmake build options to compile Akregator without Akonadi (AKREGATOR_USE_KRESOURCES and AKREGATOR_USE_AKONADI), such as is supported in KAlarm (KALARM_USE_KRESOURCES and KALARM_USE_AKONADI). Thank you! :) Reproducible: Didn't try
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?