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

List:       kmail-devel
Subject:    grmph... (was: [PATCH] filter changes).
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2001-04-26 20:20:15
[Download RAW message or body]

kmail-admin@master.kde.org wrote:
> 
> Your mail to 'Kmail' with the subject
> 
>     [PATCH] filter changes
> 
> Is being held until the list moderator can review it for approval.
> 
> The reason it is being held:
> 
>     Message body is too big: 55553 bytes but there's a limit of 50 KB
> 
> Either the message will get posted to the list, or you will receive
> notification of the moderator's decision.

====== original message w/o patch:

Marc Mutz wrote:
> 
> Hi!
> 
> The attached patch is against yesterday's or so CVS-HEAD. I've developed
> this patch in the 2.1.1 branch, and then proted it to current CVS. I
> made sure that it compiles. There was the "g++ ... -o foo.moc" error
> again, which went away (at least for me), when doing "make distclean;
> make -f Makefile.cvs; ./configure" again.
> 
> Please test and comment. There is still some stuff left to do, but I
> want people to help test (and yes, I've tested it quite a bit :-).
> 
> What this patch does:
> 
> 1. The search rules are now represented as a class KMSearchRule, the
> list of them, together with the name (which filters use, too) and the
> operator "and" or "or" to connect them, forms a KMSearchPattern.
> 
> 2. The editing of KMSearchPattern's is now encapsulated into the
> QWidget-derived class KMSearchPatternEdit. This class will be re-worked
> soon to use the KWidgetLister, see below.
> 
> 3. The filter actions are still KMFilterAction's, but a KMFilterAction
> is no longer an QObject. Also there are many more base classes from
> which you can inherit if you want to implement filter actions. These
> additional base classes hierarchy is determined mainly by what parameter
> an action takes. See the attached nano-HOWTO for more about actions.
> 
> 4. A list of KMFilterAction's can now be edited by feeding them to the
> KWidgetLister-derived class KMFilterActionWidgetLister. KWidgetLister is
> a widget that manages a set of other widgets in rows and allows to add
> new widgets at resp. remove them from the end (It's what managed the
> more, fewer and clear buttons).
> 
> 5. A KMFilter is now essentially a KMSearchPattern (though I decided not
> to make it a real subclass) plus a list of KMFilterActions. There was a
> slight api change to that class, since the name is now stored in the
> embedded KMSearchPattern. The following substitutions now hold:
> 
> KMFilter::matches()     => KMFilter::pattern()->matches()
> KMFilter::{setN,n}ame() => KMFilter::pattern()->{setN,n}ame()
> 
> 6. The KMFilterDlg is now a subclass of KDialogBase. It's main area
> contains a KMFilterListBox, which manages it's own (deep) copy of the
> filter list now and allows to change the order and the name of filters,
> as well as creating new and deleting existing ones. The filter list is
> (purified and) written back to the KMFilterMgr when the slot
> KMFilterListBox::slotApplyFilterChanges() is called. KMFilterListBox
> surrounds the update with KMFilterMgr::{begin,end}Update() calls, wich
> are currently no-ops. I'm not sure if control can be taken away from
> KMFilterList::slotApplyFilterChanges() between those two function calls.
> 
>   KMFilterListBox spreads a reference (KMFilter*) to the edit widgets
> when a new filter has been selected/highlighted. The current convention
> is that if KMFilterListBox emits a NULL filter, this means that the edit
> widgets should reset themselves and make put all changes back from their
> internal representation (e.g. stored in widgets) into the given
> KMFilter. I'm thinking about making emitting an extra signal for that in
> the future, because I find the current situation ugly.
> 
> 7. The compile-time limit for the number of search rules in a search
> pattern is currently 8, with a maximum of 26. The compile-time limit for
> the number of filter actions in a filter is also 8, with no maximum
> (well, at most as many actions as a QList can hold items and a QLayout
> can have children...).
> 
> Known bugs:
> 
> o When deleting the last filter, the then-last filter is shown in the
> edit widgets and highjlighted, but not selected. I want to make the
> listbox behave like the list boxes in the kdeui toolbar configuration
> dialog. Then this is a non-issue.
> 
> o KMFilterActionFilterApp is currently broken; KMFilterActionExec is
> untested. They will be ported to use K(Shell)Process.
> 
> What is to be done:
> 
> 0. Fix the above bugs and all the ones people will report.
> 
> 1. Adding new filter actions (see attached filter README)
> 
> 2. Porting KMSearchRuleEdit to use KWidgetLister.
> 
> 3. Extending KMSearchRule{,Widget} to allow pseudo-headers "<size>",
> "<date>", "<priority>", "<status>", etc.
> 
> Enjoy,
> 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)
> 


-- 
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.filteractions.README.bz2" (application/octet-stream)]
_______________________________________________
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]