Re: ONLY start KMail?

Ingo Klöcker <[email protected]>
Newsgroups gmane.comp.kde.users.pim
Message-ID <[email protected]>
On Thursday 13 May 2010, Thomas Taylor wrote:
> On Wed, 12 May 2010 18:24:09 -0400
> 
> John Aldrich <[email protected]> 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

_______________________________________________
KDE PIM users mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kdepim-users
signature.asc (application/pgp-signature, 198 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEABECAAYFAkvrxBUACgkQGnR+RTDgudgVNgCfSLCJwd7uuBTdWFzjeGzhSVuJ
us0AoLIbAIwE0X8nl4IAyKcH+DB/BwlK
=7oIO
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.