[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:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2004-01-31 12:46:44
Message-ID: 200401311346.56776 () erwin ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 31 January 2004 09:53, Don Sanders wrote:
> On Saturday 31 January 2004 06:39, Ingo Klöcker wrote:
> > On Friday 30 January 2004 02:33, Don Sanders wrote:
> > > On Thursday 29 January 2004 17:33, Andreas Gungl wrote:
> > > > Don Sanders wrote:
> I wonder what the filter(s?) created by the spam wizard will look
> like. I mean will there be one filter that pipes through the spam
> tool, and then a subsequent filter that checks to see if the
> X-Spam-Flag is set to something and if so moves the message to the
> trash?

Yes. See AntiSpamWizard::accept() in antispamwizard.cpp.

> > 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.

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.

> 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.

> > 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.

> > And the problem
> > with manipulating the XMLGUI file would no longer be a problem if
> > we simply add the classification actions to the default toolbar.
>
> Yeah, if we could get some attractive spam/ham toolbuttons I think
> they could make quite an attractive pair in the toolbar.

I'm no artist, but I stole the recycle icon from folder_recycle (or 
whatever the icon was called) and made a few icons for this. See the 
icons for Mark Message as Spam/Ham. I used the recycle icon because at 
least Mozilla (IIRC) also use a recycle icon (though they use the usual 
triangular recycle symbol).

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]