GNOME Bugzilla – Bug 219039
[FEATURE REQUEST] Thread View (part 2)
Last modified: 2004-05-07 18:55:32 UTC
Package: Evolution Priority: Normal Version: 1.0.1 Synopsis: [FEATURE REQUEST] Thread View (part 2) Bugzilla-Product: Evolution Bugzilla-Component: Shell Description: When in a threaded discussion view (CTRL+T) have the received column sort by newest unread message. ie, instead of displaying in first message in a conversation order, show those discussion that have new unread messages up the top. But still display the discussion in correct date order Unknown reporter: andrew.hatfield@secureone.com.au, changed to bugbuddy-import@ximian.com.
I would like to add that this is my single largest frustration with Evolution right now. My mail is very hard to read (because I get hundreds or thousands of messages a day) without threading, but if I turn threading on, messages get lost because they get put into "old threads". I need a way to view my messages in a threaded form, where the most recently updated threads are shown first. The "age of a thread" as measured by the sent/received times on the root message of the thread is a meaningless measure to me (though I'm sure someone will find it the more valuable way to go). I'm even tempted to call the current thread sorting an outright bug, but that's not fair. It's more of a design limitation than a bug. That means it's a feature, right? ;-)
can you illustrate what you want? I think I understand but am not 100% sure.
Evolution groups the thread correctly. However, when you are in a threaded conversation view and have sort by received date, the threads are listed in first item received order. This is more than mildly anonying, as you have to search through the folder to find the unread conversation threads. Can we have the ability to push unread to the top? You can't just show unread items as you will loose the "thread" of the thread (so to speak)
well, the problem is that we are doing sorting based on a per-level basis ie, toplevel nods are sorted, each of their children are sorted, whose children are also sorted, etc. it's a lot more complicated to go scanning all children of a node and use the most recent date to compare. It will also mean that sorting with threads will be slow as hell.
i know how to fix it, but etable is the problem :( it should only sort on the top nodes in tree view, and not reorder the following nodes at all.
*** This bug has been marked as a duplicate of 203206 ***