From kmail-devel Mon Jun 06 21:51:24 2005 From: Heiko Hund Date: Mon, 06 Jun 2005 21:51:24 +0000 To: kmail-devel Subject: Re: Sieve support in KMail Message-Id: <200506062351.24840.heiko () ist ! eigentlich ! net> X-MARC-Message: https://marc.info/?l=kmail-devel&m=111809472115364 On Monday 06 June 2005 22:33, Martijn Klingens wrote: > On Monday 06 June 2005 21:34, Andreas Gungl wrote: > > Am Montag, 6. Juni 2005 21:11 schrieb Heiko Hund: > > > Do you really want to go there? I think it will be hard to develop > > > and even harder to understand for the user. I understood the idea > > > that filters are transparent to the user, that she doesn't need to > > > care where the filters are stored, but somehow get a itch from the > > > idea. After all sieve filters should not be confused with local > > > filters. Mixing them together in one dialog will IMHO cause a lot of > > > confusion. What are your feelings about a separate dialog for the > > > sieve stuff (just like we did it with pop-filters back then)? > > > > I share this POV. Mixing the capabilities of sieve filters and local > > filters in one configuration frontend will make the user helpless. You > > have vacation and bounce on the sieve side, execution of scripts or > > piping through filters on the other (local) side. You could mix both > > worlds in the GUI and you'll never know what will end on the server. > > You guys are thinking too technically :) We _are_ technically technically =P > From a user perspective you just want to create a filter, period. Whether > it's a POP3 filter (wth is that a separate menu entry?), an IMAP filter, > procmail, or whatever doesn't matter the least. Generalisation is a good thing where it occurs naturally, I agree this far. But here none of the filters have stuff in common (ignore the common subset for me, would ya) except that they are called filters. Sieve filters (lets call them so) get applied when a message arrives on the mailserver. Pop filters before the messages get downloaded from a server and local filters after they arrived locally. Another difference is that sieve scripts are stored centrally where the other two are stored locally. Also sieve scripts are per (imap) account the others are IMHO per installation. > The only distinction that you *may* want to make is whether a filter runs > on the server or not, and Thomas Zander was IMO right at the PIM meeting > that even that is too much asked in general. Hiding details where possible and useful is the right thing to do. But I don't see that rule applicable here. As the technical guy I know what I want and I choose the right dialog for that. If I only know that I need a filter and I know nothing about POP3, IMAP and/or fetchmail how should I choose the right settings for my unified filter? Why can't I store the filter on the server? I have a POP server I get my mail from, but the entry stays greyed out... seems I need to RTFM. My point: why should the fine manual not be consulted _before_ making a filter (if unsure). You'll piss off users who know their stuff, plus you hide information from the one who don't. That is one thing I always disliked about Windows(tm). You don't have to know a thing to get started, and you'll probably get around after learning some GUI, but you'll never understand the concept behind it. And in this very case we are discussing the concepts differ much. I think any user who cares for filters will be willing to learn about the different types of filters there are (they are not too much for an overview). That keeps the interface clean and comprehensible. (I'm sorry I had to mention Windows in this paragraph) Also the technical and not so technical users gain from this approach. The is no need to subset functionality of one specific filter. In your first mail you had to mention so many exceptions for the 'unified filter dialog' because the filters are not compatible. Keeping them apart will IMHO do them good. > So far however my opinion, and Thomas'. Now there's also two opinions > against, so could one of you elaborate why a user would feel helpless > instead of helped? Hmm, good point. The more advanced users will probably feel helpless, betrayed and get laughed at by the guys in the office that always told them to stick with mutt. =) The less advanced users will probably cope, understanding the dialog instead of the concept. I as a techie say: nay. Can't really speak for the not so techie people, but think they should be able to differ between the types of filters. Could you sketch a unified filter dialog in words for me? I imagine it overloaded with radios and checkboxes for the exceptions, many of them grayed out since the currently chosen protocol doesn't support a feature. Regards Heiko _______________________________________________ KMail developers mailing list KMail-devel@kde.org https://mail.kde.org/mailman/listinfo/kmail-devel