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

List:       kmail-devel
Subject:    Re: Architectural problems shown by the anti spam wizard
From:       Andreas Gungl <a.gungl () gmx ! de>
Date:       2004-01-31 21:04:14
Message-ID: 200401312204.24096 () gungl-dd ! de
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Samstag, 31. Januar 2004 13:46, Ingo Klöcker wrote:
> On Saturday 31 January 2004 09:53, Don Sanders wrote:
> > On Saturday 31 January 2004 06:39, Ingo Klöcker wrote:
> > > Isn't this a prime example
> > > for the usefulness of ad-hoc filters? AFAIU the purpose of ad-hoc
> > > filters is to provide a way for the user to apply filter actions to
> > > messages. So what's wrong with creating ad-hoc filters for
> > > classifying messages as spam or ham?
> >
> > I'm a bit unhappy with the filter criteria groupbox area appearing
> > for ad hoc filters. I guess I would like to be able to get rid of it
> > for ad hoc filters. I guess I would like to be able to click on the
> > 'fewer' button a few times to make that widget collapse into a state
> > where it is obvious that the filter always matches.
>
> Actually I had thought about making a second configuration dialog for ad
> hoc filters. I don't like the "Add this filter to the Apply Filter
> Actions menu" checkbox (mainly I don't like the wording, but I couldn't
> come up with a better one). An alternative might be to add a Filter
> Type selection. Then the Filter Criteria box could be hidden for ad-hoc
> filters. But: I think it does make sense to specify a filter criteria
> for an ad-hoc filter.

I had a problem to realize that ad-hoc filters (when only this checkbox is 
marked) are not applied during manual filtering. I found it out by testing 
it, but IMO it's not clear after one has read the checkbox description. 
Having filter rules for ad-hoc filters is okay, you might want to use them 
on manual filtering too. On manual filtering the rules would get checked, 
but when you use them ad-hoc then the action is applied without checking 
the rule.

> Currently the user has the following options:
> - With "Message->Apply Filters": Manually apply all filters which are
> marked as "Apply this filter on manual filtering" on the selected
> messages.
> - With "Message->Apply Filter Actions->Filter Action Foo":
> Unconditionally apply a filter action (of an ad-hoc filter) on the
> selected messages.
> - With a search folder: Search for all messages which match certain
> criteria and then act on those messages.
>
> What the user currently can't do is: Select some messages and then
> manually apply a single filter.
>
> If ad-hoc filter would honor the filter criteria (which they currently
> don't AFAIK) then this would be possible. Alternatively we could
> unconditionally add all filters to a "Message->Apply Single Filter"
> submenu. But I guess most of the filters in this sub menu would never
> be needed by the user and would therefore unnecessarily clutter this
> submenu. So my proposal is as follows:
> - Rename "Message->Apply Filter Actions" to "Message->Apply Single
> Filter".
> - Honor filter criteria if filters are applied ad-hoc.
> - Add a radio button "Filter matches always" additionally to the "Match
> all/any of the following" radio buttons. Many users might not realize
> that empty filter criteria match always, especially because previous
> versions of KMail deleted filters with empty filter criteria.
>
> > I guess the use of ad hoc filters by spam filtering is bringing out
> > or reminding me of weaknesses that I find objectionable in ad hoc
> > filters.
>
> I hope the above proposal addresses most of your concerns.
>
> > > Also I don't understand what the advantage of hardcoding the
> > > actions would be. I mean why did you invent ad-hoc filters if you
> > > now propose to hardcode the spam classification action although
> > > ad-hoc filters are perfectly suited for this task.
> >
> > Will the spam wizard allow the existing (ad hoc) spam filters to be
> > edited?
>
> No. The purpose of the antispam wizard (as it's currently implemented)
> is to make initially setting up spam filtering in KMail as easy as
> possible.

IMO this is the most important thing for someone starting with Linux and 
KDE. If the distributor includes one or more spam tools into the default 
installation then the user can start KMail, run the wizard once and then he 
has a basic working configuration of spam filters.

> > This would be easy if hardcoded filters were used. I think it
> > could also be done if ad hoc filters were used and KMFilters had
> > unique ids.
>
> Hmm, the problem is that the antispam wizard doesn't know the unique ids
> of the filters it has setup. So those ids would have to be stored in
> the config file. Then it should be possible for the antispam wizard to
> load the current state and allow modifications.

I'm not sure how many people would like to have this additional 
funtionality. Of course, it would improve the situation once more. I would 
wait a bit and when we geta lot of feedback into this direction we can add 
it somehow.

> > > Independently of this, the general problems have to be fixed as
> > > well. A solution for the uniqueness and constantness problem of the
> > > action names (which I already mentioned it in my other message)
> > > would be to give all filters a unique identifier.
> >
> > Agreed. So how about a QString KMFilter::id() method?
> >
> > I suggest considering making KMMsgDict::getNextMsgSerNum() public and
> > using something like :
> >   int random = whatEver;
> >   int serial = kmkernel->msgDict()->getNextMsgSerNum();
> >   filterId = QString( "%d:%d" ).arg( serial,0,36 ).arg( random,0,
> > 36);
> >
> > Rather than using a random number alone. Less chance of collision due
> > to a broken clock.
> >
> > All KMFilters could be given a name when they a constructed (0 means
> > make one up). KMMainWidget::initializeFilterActions could be updated
> > to use these ids.
> >
> > Well that's the approach I think makes sense.
>
> I agree.

It's a good approach. What I've been additionally thinking about in the last 
days is whether it would give KMail a benefit if it were able to somehow 
group the filters. I think of it as a tree where the leaves are the 
filters. You might order it by account or by identity or you might want to 
group related filters (let's say mailing list filters). You could group it 
by activation and e.g. you could separate ad-hoc filters into a group of 
it's own. We even might have icons showing in which situation the filters 
get applied (incoming, outgoing, manual, ad-hoc). I'm not sure whether the 
current strategy of storing those data as ordered filters into kmailrc 
would suite. Perhaps a switch to a separate filter config file would make 
sense then.

Regards,
Andreas
- -- 
    ~
  ' v '
 //   \\
/(     )\  Powered by Penguin.
  ^ ' ^

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQFAHBhVVhjiFd4beU8RAp0HAJsEMRSCBvjZOmh19ulAf8FmGXlgUQCg+bDn
dKQNoMh7B7VGkAPLwWNmaqs=
=ADQt
-----END 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]