GNOME.org
 

Re: [Evolution] feature request: filters management

Hey, man, i'm really glad you didn't let the thread die with your
previous message. I appreciate.

On Wed, 2002-06-19 at 13:43, Not Zed wrote:



On Thu, 2002-06-20 at 11:22, Florin Andrei wrote:

I would like to see two butons in the Filters utility: "Move all the way
up" and "Move all the way down".


This would probably solve some filter management problems, and is
certainly easy enough to implement, but it doesn't seem like a generally
useful solution to the problem of managing large lists, as you allude to
later in this mail.


Yup, i agree. It's not _the_ solution.

But, then again, i probably would never started this thread if i already
had those buttons. You know, once you go beyond 100 rules, it gets kinda
nasty. Just moving one rule all the way up is a chore.
And, like you said, the implementation is trivial.

Why can't i just drag a rule in the list up or down with the mouse? Is
this some kind of GTK "feature" or something? :-/
If i could drag the rules, i would never touch the Up/Down buttons.


Also, it would be nice to be able to define "filter categories" and
configure the order of the categories.
This way, if i define a filter in the category that's at the beginning
of the chain, i'm sure it goes before many others, and i only have to
tweak the order of the filters inside that category.
Same for categories at the end of the chain.


Do you think this would map, for example, to a tree (as mentioned
elssewhere)?  Where the priority order is still determined by the
vertical order of a fully expanded tree, but it would let you hide a lot
of rules.  I'm not sure how you would easily represent order and
multiple categories without a tree.


The tree idea is quite clever. If implemented, i would use it without
remorse.

My initial idea is somewhat different. I originally thought of two lists
instead of one: one list for categories, the other for rules.

See? Imagine the Filters window; instead of just the filters list, make
it display two lists: the left one contains categories, the right one
contains actual rules. When you select a category, the rules displayed
in the right list are the ones contained in that category.
The buttons (Add, Delete, the move buttons) should be duplicated for
each list; except, perhaps, for Edit, for wich i don't quite see an
equivalent in the categories.
Oh, wait, you need Edit to rename the category.

By default, there should be one category: All, or Default, or something
like that.
When you create a new rule, there should be a select menu or something,
allowing you to drop the rule in the appropriate category. By default,
the menu should point to the currently selected category, or to the only
category if only one exists. This menu should provide a nice way to move
a rule from one category to another: just Edit a rule, change the
category in the menu... done! :-)
(i'm using the word "menu" but i'm sure it's not the right one; you got
the idea anyway)

Frankly, i cannot tell wich one is better: the tree model, or the
two-lists model. The former is fancier, the latter is (i think) easier
to manage/understand for laypersons.


I usually create four types of filters. All of them have "stop
processing" as the last action. Except for the first category, the only
other action of the filters is usually "move to some folder".

1. anti-spam, anti-stoopid, anti-kaka. These are right at the beginning,
and their default action is "delete, then stop processing"


Why aren't these just one rule?


Actually, right now those are just one, indeed. :-)
I had more than one when i needed some variations.


2. cronjobs: these are messages sent by automated processes. I want to
filter them out into their own folders, no matter how they reach me (via
mailing lists or directly)
3. mailing lists


One of the ximian guys had an idea, i think for filters (it may have
been for vfolders) where you have a single meta-rule that automagically
maps a bunch of mails to different mailing list folders, without having
to have a separate rule for each.  I'm still not fond of it because the


What do you mean by that?
Create folders automatically, assign names automatically to them, then
filter out messages to them as the messages arrive? (i mean, the
messages trigger folders creation when they arrive?)
That's rather a big security risk. Just imagine those nasssty clever
crackers out there, carefully designing e-mail headers to bomb the hell
out of Evo's directories structure. ;-)


mailing list detection code is sketchy, so you probably need specific
rule matching in each case anyway.  But that might be another option,
specify a bunch of lists you're interested about in the rule, and the
matching folders they should move to.


I still don't see how do you associate lists with folder names?...


4. humans: these are after the mailing lists, because i want to keep
personal messages from humans (not from cronjobs) in separate folders
only when they come directly, not through a mailing list

Problem is, i have like 200 filters, and when i define a new one, it's a
chore to move it up to its category.


I really do stand what i said before.  If you have this many rules, you
should probably consider using procmail, with a maildir backend.


I agree with you: there should be a limit, beyond wich Evo should give
up and let other things, more sophisticated, to take over e-mail
filtering. I just think we have different ideas on where the limit
should be.
Please remember that there are many "power-users" out there, people who
are quite computer-savvy, for wich such a setup (hundreds of folders,
hundreds of rules) is not difficult to grasp conceptually, nor difficult
to manage in actual fact. But they just don't know squat about procmail,
regex and stuff like that.
One example should trigger the right image in your mind: think of your
typical talented 2D artist, who's far above the layperson in the matter
of dealing with computers, but who never, ever, touched procmail, nor
plans to do it in any conceivable future.
Heck, i know some programmers who know nothing about procmail, do not
intend to learn it, and never (presumably) will.
In fact, more and more people become, these days, quite computer-savvy,
but without necessarily understanding such low-level things as procmail.

Not to mention the fact (once you suggested the usage of maildir) that
Evo has difficulties with maildir when you have hundreds of folders,
tens of thousands of messages, some folders with thousands of messages.

I used to use maildir with Evo (i think it has several intrinsic
advantages over other formats), but i migrated back to the default
format, because Evo was just waaay too damn slow.
Once back to default format, it became fast again.
So... it's a catch-22: you need maildir to filter with procmail when you
have an unholy large number of folders/messages, but Evo cannot scale
very well with maildir.


Evolution works quite fine with this kind of setup, and it lets the
filtering happen in the background without evolution running, and a lot
lot more flexibility and managability.


I would definitely like to do that for more than like two...three
hundred folders or so. But, as i said above: scalability?


Without much work we could probably implement a filter rule that just
ran messages through procmail rather than doing the filtering ourselves.


Well, then, how about sticking a nice little button to the Filters
window, saying: "Export as procmail template" or something like that?
Click on it, and there ya go, you get all your rules exported as a
procmail file.


The filter code was designed for 'the average Joe, and then a fair bit',
not every conceivable mail usage pattern imaginable.


Like i said above, we agree on the necessity of a limit, but perhaps
we're seeing this limit in different places.


Not to mention it's impossible to validate anything, the list is
unmaintainable, and overall the filters management is horrendous once
you have more than like 100 filters (wich happens very easy these days).


I think any gui solution will meet this same problem.  It might take
more filter rules, but it will happen.  The windows 'tcp' setup window
is really fine if you're configuring 2 machines, but after 10 it gets
rather tiresome ...  The windows explorer's expanding tree is fine if
you're managing 100 directories, but hit 1000 and it isn't so easy to
use.


Yup, same as above: there should be a limit somewhere.


If i were able to specify the category when i create a filter, it would
be much easier. Then it's only a matter to tweak the order inside a
category.
Of course, the order of the categories themselves has to be modifiable.


Well, if it was a tree it would be explictly assigned.  I guess even if
the gui isn't a tree it would be stored the same way anyway.

I think there's some bug about improving the filter/vfolder gui, but i
think its looking at some stuff nobody cares about terribly.


Probably it's one of my bugs, opened under a very low priority:

http://bugzilla.ximian.com/show_bug.cgi?id=25621
http://bugzilla.ximian.com/show_bug.cgi?id=25620
http://bugzilla.ximian.com/show_bug.cgi?id=25619
http://bugzilla.ximian.com/show_bug.cgi?id=25618

And, hey, what do you mean nobody cares about'em?
I'm going to come to Boston and beat you'all up! :-)

-- 
Florin Andrei

http://florin.myip.org/
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]