[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdepim-users
Subject:    Re: [kdepim-users] Searching x 2
From:       Anders Lund <anders () alweb ! dk>
Date:       2012-01-29 9:24:19
Message-ID: 3027095.7TgB7O9U1m () katja
[Download RAW message or body]

S=F8ndag den 29. januar 2012 09:36:48 O. Sinclair skrev:
> ~qdbus org.kde.NepomukServer /nepomukserver quit
> ~rm -rf $(kde4-config --localprefix)/share/apps/nepomuk/
> ~nepomukserver &

That (rm step) removes the nepomuk data, thus forcing it to redo everything=
, =

and also deleting valuable data if you generate any yourself (by tagging, =

commenting or rating files).  I don't think that step is nessecary. I have =
not =

practiced that, and all my mail is indexed and searchable - just not from =

within kmail. A proof of that is that typing a word that is in a mail body =
in =

krunner (ALT + F2 if you run kde) brings a reference to that mail, albeit =

currently useless as stated earlier in this thread.

> helped me at least - though search is still pretty useless. Search for =

> filename "current" and get totally unrelated mp3 files on "top" of =

> search results. KFind works way better.

You are searching for mail file names using dolpin? I have learned yesterda=
y =

that mail is not stored in the directory your storage resource points to, b=
ut =

rather a hidden directory of the same name, so that if you use default stor=
age =

of ~/.local/share/local-mail, the mail is actually in ~/.local/share/.local-
mail.directory (notice the dot in the last directory name).

That is a *bug*.

I really don't think the problem is with nepomuk, I believe it is some bug =
in  =

akonadi or its agents. That is only my impression though, but for me, nepom=
uk =

generally does a very good job.
 =

> Sorry am a bit fed up with the whole thing.

Yes, me too, it appears that if I want to use kdepim 4.8 kmail2

* mail is not storaged where configured
* search is not possible.
* search using nepoumk krunner finds items, but can not open them correctly.
* filtering is not possible, because if enabed, akonadi will infinitely =

duplicate mail.
* address completion is not working
* operations moving a lot of mails takes *very* long time and renders the =

system unusable meanwhile, and might require restarting akonadi, nepomuk an=
d =

kmail (importing a folder of 3000 messages is like that, moving them within =

kmail2 not quite so bad, but still bad)

For me, the mosta annoying thing during normal workflow will be the missing =

filtering and address completion. =


Philosophically seen, the wrong location of files is the worst. =


Psycologically seen, the potential overtaking the system for a long, undefi=
ned =

period is the worst (I will not feel comfortable not checking mail for a we=
ek =

for example, as the potential horror of receiving many mails at one time is =

scary)

On the upside, kmail2 is actually very spiffy and well working, those "smal=
l =

details" aside. And for me, updating the rest of kdepim have a very big val=
ue, =

esp korganizer that I use quite a bit with many (well, 5-7) resources have =

improved drastically in usability, and kaddressbook can now show all my =

contacts from different resources in one list, which is very handy.

For now, my plan is to try if I can live with kmail2 while it gets fixed. =

Alternatively, I think the quality of kdepim 4.8 in general will make me us=
e =

some othe mail client meanwhile. =


-- =

Anders
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users
[prev in list] [next in list] [prev in thread] [next in thread]