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

List:       kmail-devel
Subject:    Re: Full Text Indexing for KMAIL: SUBMISSION
From:       Ingo =?iso-8859-15?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2005-05-28 11:56:16
Message-ID: 200505281356.22577 () erwin ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 28 May 2005 06:03, Andreas Gungl wrote:
> Am Freitag, 27. Mai 2005 22:56 schrieb Luís Pedro Coelho:
> > After a couple of versions and a month of ironing out many small
> > issues, I think that the I have a submission ready version of my
> > full-text indexing patch for kmail. Right now it does the
> > following:
>
> Hi Luis, this promises a great enhancement for KMail. I'm looking
> forward to try it out in the office.

Yeah, I'm also looking forward to seeing it in action. But before you 
commit can you please briefly describe what dependencies we get? And 
where do you want to put your index library? kdepim? kdelibs? Somewhere 
else?

> > - indexes all your mail on local and dimap folders. This is done
> > "on the background" with small overhead over normal usage. It can
> > be done over several sessions since it takes a long time.
> > - filters your email using the search bar
>
> Somehow I feel I would be quite surprised to see the search via
> search bar extended to the body of the messages. I'm used to the
> current behavior and I might hit unexpected situations e.g. when
> deleting mails with a certain text in the subject (and unfortunately
> a lot of other messages get deleted as well because they have that
> text in the body). Can we make the search bar aware of that
> difference (e.g. have a checkbox or whatever)?

No. The quick search is already complicated enough with the additional 
Status drop down list.

Whether or not the body of the message should be included in the quick 
search is arguable. Basically the only argument against is that people 
who are used to the current behavior might get unexpected results. 
OTOH, searching also the message body is useful because the user might 
remember a few keywords but he doesn't necessarily remember the subject 
or, even worse, the sender didn't set a subject. People are used to 
Google-like behavior, i.e. full text searches. Of course, this implies 
that we have to change the way the search phrase is interpreted, i.e. 
we have to interpret it as list of words that should be contained, but 
not as phrase that needs to match exactly. (IIRC the full text search 
already does this?)

FWIW, after some discussion at the KDE PIM NL meeting I'm very much in 
favor of using the full text search for quick searching.

> > The only remaining issue I see is packaging. Right now, the kmail
> > code depends on the indexing library being installed.

So you really want to release the library as external package? In this 
case it must at least (also) be in kdesupport.

> > Probably the 
> > best thing would be if ./configure autodetects the indexing library
> > and conditionally compiles kmail with or without it.

I don't think that's a good idea. The library should not be optional but 
mandatory. If it's optional then some distros might miss including it. 
But if it's mandatory then it needs to be easy to find.

> > Users and distros should get the package at its source.

That's why I propose to at least put a copy into kdesupport. At least, 
as long as the library isn't included in the majority of distributions.

> > Could anyone help me 
> > out here? I would need help in figuring the best way to make the
> > library "findable"

"findable"? You mean the source?

> > and what the corresponding configure script 
> > should look like. Just a pointer to an example which you consider to
> > be "well done" is fine.

Sorry, I don't know a good example. You could look at 
kdepim/kpilot/configure.in.* for a complicated example.

Regards,
Ingo

[Attachment #5 (application/pgp-signature)]

_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel


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