--===============0411545759==
Content-Type: multipart/signed;
  boundary="nextPart1204885.Vtl2lQsW1z";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1204885.Vtl2lQsW1z
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday30 November 2004 00:12, Ingo Kl=C3=B6cker wrote:
> > Don't you think that it's much easier for a user to handle a "Move
> > into Folder" plus a "Copy into Folder" action?
>
> Neither "move" nor "copy" make sense for fetched messages because both
> actions require a source (from where the message is deleted in the
> "move" case and where the "original" message stays in the "copy" case).
> At least from a semantical POV "File into Folder" makes much more
> sense. OTOH, this terminology is also flawed due to the digital nature
> of email messages. There's no "the message". There are just copies of
> the message (on the POP server, in memory, in folders).
>
> Anyway, regardless of what label we use for the action IMO we only need
> one. A distinction between "move" and "copy" would just confuse the
> user. For example, what happens if the user uses "copy into folder" but
> doesn't use "move into folder". The only logical result would be to put
> a copy into the give folder and another copy into the default inbox
> (for non-IMAP accounts).
>
> > What about the usability argument?
>
> That's exactly why I don't want two actions.

So this turns out to become a philosophical discusion but a technical one...

If you insist that File into Folder behaves more in the sense of a copy=20
action, why don't you want to call it that way? I mean, this would make the=
=20
users understand what's happening.

I would be surprised to find copies of a message in several folders after=20
using File into Folders to move a message around. How should File into=20
=46older "trash" work? I mean, you still have a copy in the folder from whi=
ch=20
you intended to delete the message.

IMHO the delivery problem also isn't a problem. Fetched messages "normally"=
=20
appear in the inbox (or the specified folder). So you have at least a=20
virtual source to delete them from after applying File into Folder. That=20
you don't store them in the inbox is rather an optimization than a reason=20
to complain about a missing source folder in that case. Finally, you delete=
=20
them from the POP server (or you really have a source folder in the IMAP=20
case).

That we currently avoid subsequent moves has technical reasons. We could=20
certainly work around that and allow moving messages around via a filter=20
sequence. What's wrong with that?

Regards,
Andreas

--nextPart1204885.Vtl2lQsW1z
Content-Type: application/pgp-signature

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

iD8DBQBBrOGoVhjiFd4beU8RAuDtAJ0d7D/f9ORSi8W6QM1ioLHkffiCBwCdHqIc
c9DFhcNc7IrZ9AbgfBZ6LvA=
=5jZm
-----END PGP SIGNATURE-----

--nextPart1204885.Vtl2lQsW1z--

--===============0411545759==
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

--===============0411545759==--