-23

bcooksley wrote:The Digital Clock does use Akonadi, and no it isn't possible to switch it off.

Because I have clock on my panel I must have Akonadi?

Then please make option to switch it off or please suggest clock, that not have dependence to Akonadi. Many user don't want Akonadi. Please stop pushing it.

It would probably be better if the plasma clock simply did not use akonadi if no akonadi calendars exist.

Question: does Akonadi really add that much bloat/instability, or do "Many user[s]" not want it because they associate the fact that Akonadi uses a database to store your data with bloat? Even though I would expect that it doesn't really add all that much extra overhead over top of the user data that it stores - a small price to pay for the enhanced functionality and integration that it provides.
In the long run, which is better: a collection of disparate files containing different parts of the user data (including the probability of duplication and conflict between files) - cheap but not easy to integrate; or a (small) central database providing a singular/unified way to access user data across applications?

I suppose there is the possibility of providing a unified way of accessing user data stored in files instead of a database, but you can still speed up access by adding a config engine between the files and the applications if at least the engine provides caching of (frequently used) data. Having an engine that also allows adding remote data sources is a plus.

airdrik wrote:Question: does Akonadi really add that much bloat/instability, or do "Many user[s]" not want it because they associate the fact that Akonadi uses a database to store your data with bloat?

No, that assessment is not based on any theoretical/technical concerns with implementation details of Akonadi (which we non-developers don't really understand anyways), it's based on our own, tangible experiences with Akonadi in practice.

And while user experiences are of course subjective (and potentially misinterpreted), they're not something that should just be dismissed.

For example, my own first experience with Akonadi was like this:

After a package upgrade on my laptop, I logged in to KDE, only to find that it was *extremely* sluggish and unresponsive, and my disk monitor showed continued disk activity for no apparent reason, all of which was very unusual. So I took a look at the list of running processes, and saw several processes with akonadi in their names, which had never been there before. Killing those processes made them instantly respawn again, which in itself was frustrating enough.
The UI was so unresponsive, that I had to kill the X server (including KDE), and investigate the problem from a new non-KDE X-session. I found that running individual KDE apps didn't cause the problem to appear, but as soon as I ran plasma-desktop, the problem appeared. I ran systemsettings, and looked for an option to disable Akonadi (thinking that, surely, there must be one - just as there is one for disabling strigi), but there wasn't any (again: frustrating).
I then looked online, and found out that I wasn't the only one with this problem (or similar resource-hogging problems related to Akonadi), but that the developers nevertheless thought that users shouldn't be allowed to disable it in systemsettings.
Luckily, though, I also found a how-to for disabling Akonadi through some obscure undocumented config files or console commands or something (don't remember the details).
I followed that how-to, started up KDE again, and - except for an error message box complaining about the missing Akonadi - all was fine.

So don't tell me I only associate Akonadi with bloat because I have some theoretical prejudice against databases...

airdrik wrote:Even though I would expect that it doesn't really add all that much extra overhead over top of the user data that it stores - a small price to pay for the enhanced functionality and integration that it provides.

Not if you don't want to use that functionality.

Not every PC is used to run PIM applications! So why should a PIM data storage and abstraction engine be forced on it at the desktop-environment level?

Even if the extra overhead were "not really all that much", it's certainly not "a small price to pay" for those users for whom the benefit is zero.

airdrik wrote:Even though I would expect that it doesn't really add all that much extra overhead over top of the user data that it stores - a small price to pay for the enhanced functionality and integration that it provides.

Have you ever used laptop? I think no. This yours "not much extra overhead" is few minutes less minutes when working on a battery. Please consider that not everybody wants use those 'magical' somethings and at least not all the time. Thanks god developers gave us possibility to turn off those trashy nepomuk and strigi...

If you turn of Akonadi, kmail, korganiser and all of KDE-pim will cease to work.

I met a lot of the KDE Pim team at Akademy - they were all working on laptops, often low power netbooks. In fact Akonadi even runs on mobile phones.

You either got unlucky with the development snapshot you got hold of, or it was super slow doing a one time only initial import from your old mailbox folders to the new akonadi DB. Something not helped if you kill it halfway through.

david_edmundson wrote:If you turn of Akonadi, kmail, korganiser and all of KDE-pim will cease to work.

My English is that bad, or You don't understand, that I and some other users, not use kde-pim? Any! _No single app_! And for clock on panel, Akonadi must to start...

david_edmundson wrote:I met a lot of the KDE Pim team at Akademy - they were all working on laptops, often low power netbooks. In fact Akonadi even runs on mobile phones.

Nice. But don't use Akonadi. Why I must running it?

david_edmundson wrote:You either got unlucky with the development snapshot you got hold of, or it was super slow doing a one time only initial import from your old mailbox folders to the new akonadi DB. Something not helped if you kill it halfway through.

Simply I don't use Akonadi! Many users also. If You using it is good for You. Stop pushing programs that people don't want use. I don't want kill Akonadi, i simply don't want to use it.

Type in google: "akonadi diasble", "turn off akonadi". And see with our eyes. Why is there option for Nepomuk and Strigi, but not for Akonadi?

Sorry my comments were mostly aimed towards utehsa.

As for the original post - if you enter SystemSettings -> Personal Information you can tell KDE where to get its calendar from.

Try removing this.

If You aimed to utehsa then he also wrote:

utehsa wrote:Not if you don't want to use that functionality.

Not every PC is used to run PIM applications! So why should a PIM data storage and abstraction engine be forced on it at the desktop-environment level?

Even if the extra overhead were "not really all that much", it's certainly not "a small price to pay" for those users for whom the benefit is zero.

david_edmundson wrote:As for the original post - if you enter SystemSettings -> Personal Information you can tell KDE where to get its calendar from.

Try removing this.

I tried. Akonadi still whant to start on startup.

But I remove mysql backend, and installed sqlite, but it is not configured. In the end Akonadi trying to start, but only I see few errors in .xsession-errors, and Akonadi is not working. Yupi! KDE, clock and calendar continue to operate. Suma sumarum this is possible without working Akonadi.

TheBlackCat wrote:It would probably be better if the plasma clock simply did not use akonadi if no akonadi calendars exist.

Hmm, but in order to find out if there is no calendar it has to access Akonadi.

What people seem to want is a global setting somewhere that turns off PIM integration.

iria wrote:Why is there option for Nepomuk and Strigi, but not for Akonadi?

There is a difference in how these services are operated. Nepomuk is started with session login, i.e. autostart, so it makes sense to have an option to deactivate that.

Akonadi on the other hand is not, it is started on demand. So an option would have to be along "don't access Akonadi" for applications where this is optional (won't make any sense for application which use it as for their primary functionality).

anda_skoa wrote:Nepomuk is started with session login, i.e. autostart, so it makes sense to have an option to deactivate that.

Akonadi on the other hand is not, it is started on demand.

Well, couldn't that be (partially) changed?

So that Akonadi is started at session login, but *only* if it hasn't been deactivated in systemsettings? Just like strigi?

Applications (like the plasma panel clock) which have optional Akonadi-dependent functionality could then just use that functionality *if* Akonadi is already running, and otherwise, not use it. But *not* force Akonadi to start by themselves.

Applications (like KMail) which definitely depend on Akonadi to function *at all*, would of course still need to force Akonadi to start, but I don't think anybody has a problem with that.

Of course I don't know if that makes sense from a technical point of view, but from a user point of view, I think everyone could be happy if it were like this.