bcooksley wrote:I use the main systemwide mysql instance when I have Akonadi running, so I haven't had these problems.

Thanks for the tip!

Ken
(Greetings from across the Tasman, bro)

A word of encouragement - I installed 4.4.1 a couple of days ago, and kontact now works beautifully, and fast. Assuming you can find what's wrong with your installation (and most of the common problems are covered on the userbase akonadi page) you should be delighted with the result of the upgrade.

Kontact may work beautifully, but it starts very slowly. I takes almost as long to come up as it does for my machine to actually boot into Kubuntu. That is completely unacceptable. My machine IS old, but that has never stopped it from being useful.

I'm not convinced that moving Kontact to Akonadi, etc., has solved a problem nor, in my opinion, was there a problem that needed solving. I'm almost convinced that it is time to find another PIM that is not so heavy. I originally started using Kontact and its predecessors becuase of kpilot and my old Palm Zire31. Of course, kpilot has gone the way of the Dodo bird, so now I have to ask what do I have to gain by remaining with Kontact.

jglen490 wrote:Kontact may work beautifully, but it starts very slowly. I takes almost as long to come up as it does for my machine to actually boot into Kubuntu. That is completely unacceptable. My machine IS old, but that has never stopped it from being useful.

I'm not convinced that moving Kontact to Akonadi, etc., has solved a problem nor, in my opinion, was there a problem that needed solving. I'm almost convinced that it is time to find another PIM that is not so heavy. I originally started using Kontact and its predecessors becuase of kpilot and my old Palm Zire31. Of course, kpilot has gone the way of the Dodo bird, so now I have to ask what do I have to gain by remaining with Kontact.

I agree. If I could completely get rid of Akonadi it would make me happy. I don't see the need for it.

Akonadi is the future KDE PIM framework and will be replacing the older KResources framework, with KMail to be using it for its IMAP/POP/etc capabilities in KDE 4.5 as far as I am aware.

The problem at the moment is that applications are stuck between the older methods and the much newer single reliance on Akonadi, meaning that some work ( and code ) is being duplicated.

I understand what you are saying. I just hope that KDE developers are hearing what we are saying. As it stands right now, Kontact is not a good product; it is slow, its presentation is not sufficiently different to warrant calling it a "change", and in reality it has not fixed anything that was necessarily broken.

I'm looking right now for some PIM, or combination of applications, that will be a functional replacement for Kontact. Too many releases have gone by where Kontact has been touched by Akonadi, Nepomuk, and the rest, and not touched in a good way.

Now using Thunderbird and Lightning for mail, address book, news, calendar and tasks. Functionally, this does what I was doing with Kontact, but without the weight.

Hope the Kontact devs can reach their goals, but I can't wait for that to happen.

bcooksley wrote:Akonadi is a much more generic infrastructure that what previously existed. As it does not have any user interface as such, it is more well designed for long term monitoring of mail status.

I don't use kmail, and I don't want nepomuk eating my resources, I need the computer to work. Can I get rid of semantic-desktop in kde-4.4.3?

jglen490 wrote:Now using Thunderbird and Lightning for mail, address book, news, calendar and tasks. Functionally, this does what I was doing with Kontact, but without the weight.

I just changed to Thunderbird also. It works really well.

@adijbr: If you do not need to use any components of the PIM stack, it can be disabled in System Settings > Advanced > Desktop Search.

As you are using Gentoo, you may also wish to check your USE flags, which I believe have an option to disable Nepomuk functionality at the compilation level.

I tried to disable nepomuk stuff in the system config - desktop search. However the KDE system still runs the nepomuk processes in the background.

Finally I found a way to get rid of nepomuk. I switched back to gnome desktop. Sorry guys, but I have not found an other way to opt-out this garbage.

Still using KDE SC 4.4 for production, so akonadi is used only for contacts, and although I admit it does slow down the startup of kontact by 5-10 seconds (if it isn't running yet), when I tried kdepim 4.6beta on a testing machine, I found kmail to start nearly instantaneously, thanks to akonadi already running (it gets started on login). Also on this test machine, nepomuk is broken, and doesn't work at all (no idea why), yet akonadi in kmail works fine...
I personnally see a great advantage in Akonadi : all data in one place, and interfaces to connect to it means that for instance Kopete won't need to manage its own contacts, akonadi will.
Another fine example I could come up with are RSS feeds : many people will like having a plasmoid on the desktop/in panel, yet sometimes use akregator. If both use akonadi, data duplication (on disk and in memory) is gone. It could also be interfaced in konqueror or/and rekonq with "à la" firefox news feeds, still with no data duplication, and inter-app sync of read/unread items for free.
Organizer reminders, the little applet in the systray, won't have to keep its own copy of events : akonadi (in fact, I guess it could even disappear and that reminders be moved into a kded module).
IMO akonadi will enable true desktop/data integration. I hope it will become (or at least heavily influence) a freedesktop standard. *crosses fingers*
As for nepomuk, from what I understand it suffers from a lack of manpower, thus evolving slowly.

Gentoo users : USE="-semantic-desktop" to disable nepomuk.

Serafean

Serafean wrote:Still using KDE SC 4.4 for production, so akonadi is used only for contacts, and although I admit it does slow down the startup of kontact by 5-10 seconds (if it isn't running yet), when I tried kdepim 4.6beta on a testing machine, I found kmail to start nearly instantaneously, thanks to akonadi already running (it gets started on login). Also on this test machine, nepomuk is broken, and doesn't work at all (no idea why), yet akonadi in kmail works fine...
I personnally see a great advantage in Akonadi : all data in one place, and interfaces to connect to it means that for instance Kopete won't need to manage its own contacts, akonadi will.
Another fine example I could come up with are RSS feeds : many people will like having a plasmoid on the desktop/in panel, yet sometimes use akregator. If both use akonadi, data duplication (on disk and in memory) is gone. It could also be interfaced in konqueror or/and rekonq with "à la" firefox news feeds, still with no data duplication, and inter-app sync of read/unread items for free.
Organizer reminders, the little applet in the systray, won't have to keep its own copy of events : akonadi (in fact, I guess it could even disappear and that reminders be moved into a kded module).
IMO akonadi will enable true desktop/data integration. I hope it will become (or at least heavily influence) a freedesktop standard. *crosses fingers*
As for nepomuk, from what I understand it suffers from a lack of manpower, thus evolving slowly.

Gentoo users : USE="-semantic-desktop" to disable nepomuk.

Serafean

What you are describing is great but the akonadi desing, as of now, has a downside: it forces you to use akonadi. I'll explain myself: before akonadi I could use any tool available on *nix to access/modify the resources of my pim data (or whatever you want) without any problem at all. That is: I could use mutt,rsync,kmail or whatever I wanted accessing the same data without any hassle. Now that is *NOT* possible. I work as a system administrator and the fact that we are losing such powers with our pim data is... well, I believe it to be wrong .

On the other hand, I understand what the developers are trying to do as they are kinda centralizing the pim collection/management into akonadi. If you think it deeply it is the way kde does things like in the use of kdelibs. Maybe akonadi is not that wrong. Time will tell...

Regards,

Damnshock

PS: I'd like to thank the developers because even though kdepim has some downsides I still count them as a *must have* program

Note that the actual data sources are still present on your system, and can still be interfaced with using standard tools. Akonadi simply unifies the configuration and access of data for KDE apps.

bcooksley wrote:Note that the actual data sources are still present on your system, and can still be interfaced with using standard tools. Akonadi simply unifies the configuration and access of data for KDE apps.

You *cannot* write into that info as in that case akonadi will break.

Regards