[kdepim-users] ONLY start KMail?

Ingo Klöcker kloecker at kde.org
Thu May 13 10:19:16 BST 2010


On Thursday 13 May 2010, Thomas Taylor wrote:
> On Wed, 12 May 2010 18:24:09 -0400
> 
> John Aldrich <jmaldrich at yahoo.com> wrote:
> > On Wed May 12 2010, Ingo Klöcker wrote:
> > > I don't see the problem. If those Akonadi resources are not used
> > > then they won't use any CPU and, consequently, don't produce any
> > > heat. If those Akonadi resources wouldn't exist then KMail would
> > > use that bit CPU that's now used by the resources. In KDE SC 3.5
> > > the resources were hidden in-process. Now they are separate
> > > processes. That doesn't make them more CPU or memory hungry.
> > > 
> > > What you definitely want to do is disable strigi, but I guess you
> > > already did so.
> > > 
> > > Alternatively, follow Werner's example and stay with KDE SC 3.5.
> > > If all you want is email then there's no point in using KDE SC
> > > 4.4.
> > 
> > Easy enough to say, but in practice it's impossible to do if you
> > want to use a "modern" version of KDE. To use KDE 3.5, I'd have to
> > downgrade KDE completely and would not be able to use the advanced
> > features of the WM that I *like.* Unfortunately, I'd have to
> > recompile everything from scratch to stick with the "old style"
> > KMail.
> > My only question is "if these things aren't even being used, why
> > are they running in the first place?" Is it a *requirement* that
> > all this crap run in the background? Why do you require all this
> > junk just to get email? Am I going to have to sacrifice the
> > functionality and experience and get a new email client?
> 
> Unfortunately turning strigi doesn't work, it still runs as
> demonstrated by the akonadi search bar and failure in KDE 4.4.2.
> 
> listing of ~/.kde4/share/config/nepomukserverrc:
> [Basic Settings]
> Configured repositories=main
> Start Nepomuk=false
> 
> [Service-nepomukstrigiservice]
> autostart=false
> 
> [main Settings]
> Storage Dir[$e]=$HOME/.kde4/share/apps/nepomuk/repository/main/
> Used Soprano Backend=redland
> rebuilt index for type indexing=false

You are still using the redland backend. This backend is dead slow. The 
recommended backend is Virtuoso, i.e.
Used Soprano Backend=virtuosobackend

Also Nepomuk is required by Akonadi. Therefore you should enable Nepomuk 
but you can keep the Strigi service disabled.


> This problem was in openSUSE 11.2 and remains in 11.3-M6.  Drove me
> away from kmail which I liked, many useful features.

I'm also using openSUSE 11.2 and I'm not experiencing any serious 
problems with KMail, Nepomuk or Akonadi.


> For Ingo:  How about adding an export feature to kmail?  I know
> there's a rather limited import function (only mbox or maildir),

That's nonsense. KMail can import the data from most major email 
programs. Have a look at File->Import Messages if you don't believe me.


> but
> no export.  I'd like to be able to export to my wind-blows email
> program without having to forward hundreds of messages ( actually
> 4000+)

Sorry, but if your Windows email program is not able to import anything 
as simple as mbox or maildir then this is a problem of your Windows 
email program. If KMail would have an export feature then it would 
export folders as mbox. In fact, if you select all messages in a folder 
and then use File->Save As, then all messages will be saved to an mbox 
file. So KMail does have a primitive but still usable export feature.

In any case, the best way to get your mail from one email client into 
another is an IMAP account.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20100513/42300ee1/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
kdepim-users at kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users


More information about the kdepim-users mailing list