--===============2005113984==
Content-Type: multipart/signed;
  boundary="nextPart1555423.q9bqLEqiyb";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1555423.q9bqLEqiyb
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 ev=
en
> 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 filter=
s=20
in one configuration frontend will make the user helpless. You have vacatio=
n=20
and bounce on the sieve side, execution of scripts or piping through filter=
s=20
on the other (local) side. You could mix both worlds in the GUI and you'll=
=20
never know what will end on the server.

Andreas

--nextPart1555423.q9bqLEqiyb
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCpKVEVhjiFd4beU8RAvx6AKDDqBXJjK0V4grSR9YpJLx6AehkWgCgyL0b
q9BB6Gce17O4M7pi/IB6yVQ=
=jaol
-----END PGP SIGNATURE-----

--nextPart1555423.q9bqLEqiyb--

--===============2005113984==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============2005113984==--