On Die 01 Aug 2000 Joachim Ansorg wrote: > If I forward an eMail using the filter dialog the eMail which was > forwarded has the status "forwarded" although it's a new eMail! > This way I do not notice the new eMail which were forwarded. One mail can currently only have one status so what you want is a new feature. I'll set this report to wishlist. Regards Daniel -- http://www.glasatelier-naber.de
(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: 1.1.61 (using current CVS) Severity:: Normal Hi! I have a small problem with filtered eMails in KMail. If I forward an eMail using the filter dialog the eMail which was forwarded has the status "forwarded" although it's a new eMail! This way I do not notice the new eMail which were forwarded. Do you understand or is my explanation too bad? --Joachim
Folder are now also bold when subfolders contain new mail which should allow you to find the folders with new mail more easy. Displaying the total unread messages would only be confusing since top level folder can contain mail on its own.
Works for me with KMail 1.5 Now it is also possible to set status of messages when using filters. So this one might be considered fixed now (it's over 1 year old btw) Cheers, Thorsten
No, it's not fixed yet. A message still can't have forwarded _and_ unread status.
In KMail 1.6 messages will be able to have several different stati at the same time. A message can now be forwarded and unread. Toggling the forwarded status does no longer affect any other status such as new or unread.
Subject: Re: "Forward status should not affect read/unread status" On Tue, 8 Jul 2003 08:14 am, Till Adam wrote: > ------- In KMail 1.6 messages will be able to have several different stati > at the same time. A message can now be forwarded and unread. Toggling the > forwarded status does no longer affect any other status such as new or > unread. This is nice work. Thanks. One further suggestion: the options should be sensitive to what is already selected. So if I have a message that is marked as Read and Forwarded, being offered an option to "Mark Message as Read" or "Mark Message as Forwarded" is a bit confusing. In this case, it would be nicer if the menu didn't contain the option to "Mark Message as Read" (but still offered "Mark Message as Unread" and "Mark Message as New"), and offered the option to "Unmark Message as Read". In general, a message can only be marked as one of New, Unread or Read. So you'd always get the two that aren't currently marked. Forwarded, Replied and Important are independent alternatives, and should be "Mark" or "Unmark". If this is too expensive to do, it'd be OK just to use "Toggle" instead of Mark or Unmark. If we are going to get really fancy, the icon should toggle too - so you get he normal forwarded symbol with an red circle/line overlayed to show that you are removing the mark. I'm not sure about Sent and Queued semantics - they look to be independent, but I don't understand them clearly enough to say for sure. Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/DSjDW6pHgIdAuOMRAl99AJ47fEp0P1nLTPOfpEuEziBWsbZuKwCfbsug ga1AdBBFhzo4dWubCKGlssI= =xgol -----END PGP SIGNATURE-----
Subject: Re: "Forward status should not affect read/unread status" On Thursday 10 July 2003 10:50, Brad Hards wrote: > This is nice work. Thanks. Thank you. > So if I have a message that is marked as Read and Forwarded, being offered > an option to "Mark Message as Read" or "Mark Message as Forwarded" is a bit > confusing. In this case, it would be nicer if the menu didn't contain the > option to "Mark Message as Read" (but still offered "Mark Message as > Unread" and "Mark Message as New"), and offered the option to > "Unmark Message as Read". read, unread and new are mutually exclusive. Setting one unsets the others. I think having all of them available in the menu at all times is less confusing and also keeps the code cleaner. I know you don't care about the later, but in this case the extra complexity for hiding them is just not worth it, imho. ;) > Forwarded, Replied and Important are independent alternatives, and should > be "Mark" or "Unmark". If this is too expensive to do, it'd be OK just to > use "Toggle" instead of Mark or Unmark. Those are toggle actions now, so they work as you describe. > If we are going to get really fancy, the icon should toggle too - so you > get he normal forwarded symbol with an red circle/line overlayed to show > that you are removing the mark. Again, overkill in my view. > I'm not sure about Sent and Queued semantics - they look to be independent, > but I don't understand them clearly enough to say for sure. They are toggle actions as well, which can be set almost independently. Sent overrides queued. Thanks for your feedback, Brad, it is appreciated. Till
Subject: Re: "Forward status should not affect read/unread status" On Thu, 24 Jul 2003 16:58 pm, Till Adam wrote: > read, unread and new are mutually exclusive. Setting one unsets the others. > I think having all of them available in the menu at all times is less > confusing and also keeps the code cleaner. I know you don't care about the > later, but in this case the extra complexity for hiding them is just not > worth it, imho. ;) I do care about code cleanliness: 1. At some stage, I'd like to work on it. 2. Even if I don't work on it, the complexity of the code is proportional to the logic errors that users experience. More complex code is harder to understand and maintain, and that results in an increase in bugs, and reduces the number of people that can work on it. Since I don't yet have the understanding to code this, I leave it to your judgement. I wasn't trying to be unreasonable though - there is already similar functionality for handling threaded messages. RMB on a message in a threaded folder gives you a "Mark Thread ->", while this isn't present for messages in unthreaded folders. Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/JDmMW6pHgIdAuOMRAs29AKCfN8b2h9FIYsK6WNvwQXmmGY4OAgCbBK08 t8uED9DXlV0TbrfXda+4GRs= =m5aE -----END PGP SIGNATURE-----
*** Bug 57569 has been marked as a duplicate of this bug. ***