Ingo Klöcker said:
> We are obviously not talking about the same kind of user. The normal
> user just wants to setup filters. He doesn't want to think about
> whether he should setup a filter on the server or locally. In fact he
> doesn't even want to know that there's a difference (which is where it
> gets difficult). What he might want though is that his mail is also
> filtered when he accesses it through a webmail frontend or from another
> location (which is the second hard problem).

Also, given the stuff that happens at the code level we need quite a bit
more information internally.

If you add to that the long-term goal of having KMail support extensions
and scripts for powerusers that we defined in Achtmaal, this could cater
the powerusers who want a more powerful Sieve GUI. This is not my worry,
nor focus for now, we're quite far away from this (see below).

> Let's ignore POP filters in this discussion. (They have a completely
> different purpose and are IMO rightfully configured in a separate
> dialog.)

They probably deserve a renaming of the option though, I know very few
people who would understand what it means and click the option to make use
of it ;-)

> That's where we disagree. Without actual user testing which
> OpenUsability.org will most likely do for us if we ask them nicely we
> have no way to know. But before something can be tested it has to be
> implemented. I suggest we start with the common dialog.

This is also what I was thinking of last night just before I fell asleep,
but also from another point of view: pragmatism. For now we just need to
get work done, and the GUI is the least of my worries at this stage.

I suggest to leave it for now and either bring it up when it becomes
important, or even try the existing proposal that Ingo, me and Thomas
designed together and let a group like OpenUsability, Appeal or Relevantiv
provide feedback.

> You imagine wrong. AFAIU Martijn at the KDE PIM meeting the dialog will
> basically stay the same as it currently is in svn trunk. The only
> difference will be some kind of indicator for local/remote filters. The
> changes will mainly be in what happens in the background, i.e. that
> KMail will upload some filters.

Right.

> I think Martijn didn't yet know what to
> do with filter criteria and filter actions which are supported by Sieve
> but not by local KMail filters. (The other way around is no problem.)

Right again. :)

I don't have any such filters, and most of them can be handled rather
gracefully AFAIK the Sieve language now. Where it gets messy is where
Sieve scripts start to lean towards programming, with nested if and more.
It's quite easy to split that up in filters with multiple criteria, but
when writing back the file it will look quite different from the original.

Actually, I wouldn't mind if KMail had the technical support for filters like

if MailingList == kde-commits {
   if Subject contains kmail|libkdepim|kontact
       // Do something
   elsif Subject contains kopete
       // Something else
   else
       // Default
}

The GUI can move to a plugin for the moron^H^H^H^Hpowerusers like me who
have to deal with such complicated mail filters, but if the backend code
is there then supporting such Sieve filters is also easier.

It would also complicate the GUI though -- if you have such an advanced
filter setup, how is the non-advanced GUI going to show the filters?

Conclusion: let's skip it for now and get work done first ;)

-- 
Martijn
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel