Version: 1.5.1 (using KDE 3.1.1) Installed from: Gentoo Compiler: gcc version 3.2.2 OS: Linux (i686) release 2.4.20-gentoo-r2 It would be nice to be able to find all 'related' messages within, say the folder, or anywhere. most useful I can think of would be a message that has a reply icon, "Find reply" hope this makes sense, been up too long. tom
Yes ! And perhaps a tree (like for threads but in a other color) under the message to browse the related messages. Pv
Something similar was already discussed under #57746. Unfortunately, #57746 was closed without including the wish. So again: reply messages to certain mails within a thread (which are normally stored in the sent folder, not in the inbox) should be included in the inbox thread tree just as normal messages, maybe coloured differently. Tom's request is an abstraction of this, he wants "related" messages from different folders to be grouped together. The example I gave is just a special case, which for my everyday life would be strongly appreciated!! Please include this for KDE 3.3!!!
As for the original request, how would you define "related"? What kind of indicators should KMail use to "relate" two or more messages? @Johannes: KMail 1.7 from KDE 3.3 will contain a per folder option to "keep replies to mails in this folder also in this folder". Does that help?
The notion of "related" should possibly best be clarified by Tom. Regarding KMail 1.7: My suggestion would be to still store replies in the sent folder. This is more consistent to "normal" sent messages and also what users expect. Besides, to keep replies in the same folder IMHO only makes sense for threadwise grouping. Why else should you wish to keep replies in your inbox which is mostly overful anyway. So: store replies in the sent folder but for thread view include links in the appropriate position within the thread tree. Although this is certainly technically challenging (distinction between normal mails and references, scan and match sent folder mails on demand), this would be a great novice feature which from my knowledge no other mail client provides. Speaking about thread view: In my experience it would be much more practical to sort in message threads according to the newest/last/most current message in the thread and not (as currently) according to the latest/first message.
On Wednesday 28 July 2004 16:03, Johannes wrote: > Regarding KMail 1.7: My suggestion would be to still store replies in the > sent folder. This is more consistent to "normal" sent messages and also > what users expect. Besides, to keep replies in the same folder IMHO only > makes sense for threadwise grouping. Why else should you wish to keep > replies in your inbox which is mostly overful anyway. So: store replies in > the sent folder but for thread view include links in the appropriate > position within the thread tree. Although this is certainly technically > challenging (distinction between normal mails and references, scan and > match sent folder mails on demand), this would be a great novice feature > which from my knowledge no other mail client provides. I personally think this would be very confusing and unintuitive especially for novice users, but I could be wrong here. It's very unlikely, though, that something like this will be implemented in KMail. > Speaking about thread view: In my experience it would be much more > practical to sort in message threads according to the newest/last/most > current message in the thread and not (as currently) according to the > latest/first message. Yes, that's a frequent wish. It's on my todo. Till
On Thursday 29 July 2004 00:36, Till Adam wrote: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=56976 > > > > > ------- Additional Comments From adam kde org 2004-07-28 16:36 > ------- > > On Wednesday 28 July 2004 16:03, Johannes wrote: > > Regarding KMail 1.7: My suggestion would be to still store > > replies in the sent folder. This is more consistent to "normal" > > sent messages and also what users expect. Besides, to keep > > replies in the same folder IMHO only makes sense for threadwise > > grouping. Why else should you wish to keep replies in your inbox > > which is mostly overful anyway. So: store replies in the sent > > folder but for thread view include links in the appropriate > > position within the thread tree. Although this is certainly > > technically challenging (distinction between normal mails and > > references, scan and match sent folder mails on demand), this > > would be a great novice feature which from my knowledge no other > > mail client provides. > > I personally think this would be very confusing and unintuitive > especially for novice users, but I could be wrong here. No comment on the UI suggestions. > It's very > unlikely, though, that something like this will be implemented in > KMail. I think creating global rather than just per message threading info would be nice, I often wished it existed. But it would be a lot of work to get it right (persistent data easily corrupted, also requires factoring the threading code out of kmheaders), and even more work to make sure it doesn't take up too much main memory (using a disk base structure rather than main memory like for full text indexing). Don.
*** Bug 91720 has been marked as a duplicate of this bug. ***
*** Bug 92493 has been marked as a duplicate of this bug. ***
Yes, such feature would be very useful and would save me a lot of time and effort. This is how I imagine it: As we know, if an email is a reply for some other email, it is mentioned in its headers. Like that: References: <200608111958.47767.piotr.sobolewski@gazeta.pl> As far as I remember. So when an email has such header, this email could for instance have some icon or text like "this is a reply to (->)". And when I click on it, I go to this parent email (even if it is in another folder).
*** Bug 103951 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.