[Users] Create filter/proc question.

[Mark Filipak]

On 2013/4/7 6:53 AM, Paul wrote:
> On Sat, 06 Apr 2013 23:44:05 -0400
> Mark Filipak <markfilipak.linux at gmail.com> wrote:
>
>> Claws developers:
>
> This could be answered by users as well as developers.

Thank you, Paul, but no: it can't be answered by users because they don't write code. You have misunderstood what I'm asking. I'm not asking _how_ to do something. I'm asking _why_ it is the way it is. I'm asking for software architecture: How is Claws constructed and how does it process? I assume I could examine the source code, but I want to ask just simple questions and I'd like to bring you folks along in the answers. Bear with me please. You will see and you will agree.

>> 1 - I have a MH selected (highlighted). I want to create a filter,
>> but 'Create filter rule' and 'Create processing rule' in the
>> 'Tools' menu are both greyed out. The only way I can get around
>> that is to select the MH's Inbox. Why?
>
> See the manual:
> http://www.claws-mail.org/manual/claws-mail-manual.html#handling_filters

I've read the entire manual of course. It's quite short, and when I'm done it will be significantly shorter. Terse yet concise is what I'm after: not a word too short and not a word too long.

> "You will find the filtering preferences via the "Configuration"
> menu, "Filtering" item."
>
> and
>
> "There is also a quick method of creating filtering rules based on
> the selected message. After selecting a mail of the type you want to
> filter, choose "Create filter rule..." from the "Tools" menu"

Not "how", but "why". Why do I have to select (highlight) the MH's Inbox before I can create a filter? Why can't I simply select the MH? After all, it's the MH that does the filtering. By requiring me to select the MH's Inbox, it gives me the impression that the filters are attached to the Inbox as though the mail is fetched first and the filters are applied to the Inbox rather than to just the messages that were fetched - the later is called "scoreboarding" and I'll address that in the "Mail fetch question" thread.

Now, don't misunderstand me. I know that I can run a filter - well, process actually - against a mailbox (the Inbox or any other mailbox). I'm not asking about that.

>> 2 - What's the difference between 'Create filter rule' and 'Create
>> processing rule'?
>
> See the manual:
> http://www.claws-mail.org/manual/claws-mail-manual.html#adv_processing
>
> "Processing rules are the same as Filtering rules, except that they
> are applied when entering a folder or when manually applied from a
> folder's context menu and apply only to this folder."

I find this a little strange. I don't believe Eudora, for example, worked that way but I may be wrong because I've been using TBird for so many years and have become somewhat enured to how a mail application should work. I think that in other mail applications, the user may apply any filter stack against the contents of any mailbox at any time, but I may be wrong. In any event, distinguishing between the scope of a sort on the basis of whether a rule is part of a filter or part of a process seems a thin and potentially confusing (and maybe even inefficient and/or buggy) distinction. May I suggest that there really is no difference between a "filter rule" and a "processing rule"? The distinction is in their scope.

Ciao - Mark.

PS: By the way. Regarding philosophy: I have already indicated that I consider naming to be a critical design step. Poorly chosen names are the source of a great number of support calls. Well chosen names help both 'how-to's and source code. I assume you agree. What I'm writing about in this message is a filter stack. "Filter stack" is a software architecture term. If one knows what a filter is and what a stack is and how they work regarding scope and sequencing, then the term "filter stack" doesn't really require much further explanation. But it has to be referred to as a "filter stack", not "filters" or not anything else. Now, my major beef with Microsoft is: not only does it dumb-down software, but it applies inappropriate metaphors that obscure how software processes work rather than illuminate them. Overall, I'm against metaphor. I have found that it's much better to use established programming names for architectural features and then _expect_ users to know what those terms me
an. If the user doesn't know what a particular term means - aha! - there's a superscripted number directing them to a notation at the bottom of the page or to a side note or to a glossary entry - that's how to handle complicated topics! I'm reminded of the poem "Naming of Parts" by Henry Reed. The trick to all this is: you have to be consistent and you have to be right. Comments?
-- 
VMware Player 5.0.2
Host: WinXP3, 32-bit
Guest: Linux Mint 14, 64-bit + Xfce 4.10