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

List:       kmail-devel
Subject:    Re: Filter Dialog suggestions
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2001-04-03 18:11:20
[Download RAW message or body]

Don Sanders wrote:
> 
<snip>
> Agreed. The suggestions sound well thought out to me also.
> 
> If work on the filter dialog is to be done it would be nice to expand it so
> that for each filter the user can select whether to apply the filter to
> incoming or outgoing mail or both (use check boxes), or neither (means the
> filter will only be applied when the user manually filters mail themself).
> 
> Also the tab stops of the dialogs don't have a sensible order.
> 
> I'm afraid the GUI code for the filter dialog is not very elegant, it took
> quite some time to debug.
<snip> 

OK, digging through the codebase, the following thoughts occured to me:
(if something here seems strange, speak up, please: I'm not very
experienced with C++/Qt/KDE!)

A KMFilter essentially consists of two KMFilterRule's, an Operator (and,
or,...) and the KMFilterAction list, which is a normal C array.

- We have to extend this, of course, with two booleans mApplyOnIn and
mApplyOnOut, complete with get and set methods.
- mRuleA and mRuleB may be changed into a QList<KMFilterRule>.
- mAction may be changed into a QList<KMFilterAction>.
- should there be a single Operator connecting all filter rules (like in
netscape), or should there be another Operator for each KMFilterRule,
except the first? How to then try to match this:
  (if) fA [contains] cA
  and  fB [contains] cB
  or   fC [contains] cC
if e.g. the rules evaluate to (false,true,false)? Is the result:
  true ( (0&&1)||0 )
  false ( 0&&(1||0) )
? I'd vote for the common operator. Because Function has all functions
also negated.
- How to store there Filters in the config? It would be horrible to have
to write an importer for old filters.
- Why is FuncNotRegExp not provided in the filter dialog?

KMFilterRule essentially consists of the field(s), a "function"
(contains, matches regexp, etc) and a "content", e.g. the substring or
the regexp pattern.

- There should be a KMFilterRuleWidget, consisting of the editable
QComboBox for the field, the QComboBox for the Function and the
QLineEdit for the "content",
- There should be a KMFilterRulesEdit, a widget, initially consisting of
one KMFilterRuleWidget, two buttons for 'more' and 'fewer'
KMFilterRuleWidget's and two radio buttons "Match any.." / "Match all of
the following", together inside a QFrame. This widget could be reused in
the KMFldSearchDlg. Maybe the 'more'/'fewer' handling could be
abstracted away into another class (but that would be a case for kdeui).

I don't quite understand the KMFilterAction{,Desc,Dict} stuff. Can
somebody enlighten me?

If nobody opposes to this, I'd go on as follows:

1. Write KMFilterRuleWidget.
2. Write KMFilterRuleEdit:
   - Limit it to two rules.
   - Integrate it into the dialog.
3. Let sombody explain to me KMFilterAction*
4. Write KMFilterAction{Widget,Edit}
   - Corresponding to 1./2.
   - Limit it to FILTER_MAX_ACTIONS actions.
   - Integrate in into the dialog.
5. Write a KMFilterEdit.
   - Will be the right half of the dialog.
   - Allows editing of the filter's name.
6. Discuss the extensions necessary to
   drop the above limits.
7. Drop the limits, add "Don's Checkboxes".
-- the following can be done by sombody else :-) --
8. Make the methods using KFilter::matches()
   aware of "Don's Checkboxes".
9. Change the message search dialog to use the
   new rule-edit and thus allow more complex queries.

What does everybody think? Should I work on kdenetwork/kmail or
kdenonbeta/kmail2?

Marc

-- 
Marc Mutz <Marc@Mutz.com>     http://EncryptionHOWTO.sourceforge.net/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

_______________________________________________
Kmail Developers mailing list
Kmail@master.kde.org
http://master.kde.org/mailman/listinfo/kmail

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