Implemented in kmail 1.6. Please close

Really? Where? I could not find it in KMail form CVS. When I collapse a thread there it only reflects the status of the first message, not of  the child messages. Where can I set it to indicate the status of the messages in the thread?

	Rainer

Just checked this in KMail 1.6.2, changed status of last message to unread and the collapsed thread did not indicate an unread message within it.

Using 
Qt: 3.3.4
KDE: 3.3.91 (beta1) Level "a"
KMail: 1.7.2
There is still no indication of unread mails in threads! Is there somewhere that it needs to be enabled?

*** This bug has been confirmed by popular vote. ***

I would also suggest that there should be a sorting mechanism which sorts threads based on the latest mail in the thread and not the earliest mail in the thread. Currently, threads are sorted by the time-stamp of the earliest mail in the thread. That way, when a very popular thread keeps on receiving messages - it goes to the bottom. If the sorting was based on the time-stamp of the latest mail in the thread - then a new mail in otherwise old thread would bring that thread to top (or bottom) with the other unread messages. 

Also, in such cases, the thread should be expanded with only the unread messages visible inside the thread. User can further click on the thread's first mail to see all the messages in thread. 

And, of course, all the messages in thread should be bold that are unread. 

These three features together makes it a lot easier to work with too many mails and long threads. How do I know? Because, Outlook implements it this way - which I have used for years now. Please don't bash me just because I am suggesting something that is availbale in microsoft product. Just evaluate this usability feature on it's own merit - you will find that it indeed makes working with many   threads/messages a lot easier.

Osho

Not only M$, but GMail works that way. The threads are sorted based on the last post, not the first.

Sunny

Mozilla Thunderbird can do it also. I want to move away from Thunderbird, but I observe several MLs that create a good amount of traffic and without very good sorting capabilities it just takes too much time.

Dirk

Created attachment 15391 [details]
Make read messages with hidden unread children underlined.

Another quality patch! :-) (against 1.9.1)

You might want to add a new color setting and/or font setting instead, or make
the underline contigous somehow (like the strike-through for
about-to-be-deleted messages).

Comment on attachment 15391 [details]
Make read messages with hidden unread children underlined.

No, that one's obviously not good - it only looks one level down. New try...

Created attachment 15392 [details]
Same as above, but hopefully better.

Why can't you make an iterator that only iterates over the children of a
particular item?

The most pretty way might be to create a private method that can be called
recursively.

There is one more thing to do, namely repainting thus hightlighted messages when "Mark thread read" is invoked.

Created attachment 17388 [details]
New patch (against 1.9.3) that also repaints parents when a HeaderItem's status changes

Any opinions on whether my patch is basically sound or not?

Traversing all parents for each item that changes status isn't very efficient
when marking whole threads or folders unread, but AFAICS,
KMHeaders::msgHeaderChanged() is the right place to do the repainting and it's
not easy to know there which ancestor items have already been repainted.

The font style of collapsed items with unread messages below could easily be
something else, but I feel that underline works well. Also, the Fonts tab of
the customization dialog doesn't have options for underlining or other
decorations.

What's the use case for this wish? Why do you want to know which threads contain unread messages if you are not going to read those unread messages? If you are going to read them then why don't you make KMail automatically open threads containing unread messages? If you see a closed thread containing unread messages then you have to open the thread before you can read the unread messages. So I don't see the point of not having threads with unread messages opened already by KMail. And if you are not interested in threads then mark them as ignored. Then they won't be opened even if they contain unread messages.

I'm sure there's a good use case for this wish. Otherwise there wouldn't be 141 votes. So please tell me your use case.

(The fact that Outlook et al. have this feature doesn't count. Do Outlook et al. [optionally] automatically open threads with unread messages? If not, then this does obviously explain why Outlook et al. have to highlight closed threads with unread messages.)

About the patch: I don't think adding this code to paintCell is a good idea. paintCell will be called (number of visible lines)*(number of columns) times and now imagine this in a mailing list folder with lots of closed threads. Then you get O( (number of visible lines)*(number of columns)*(number of children in the closed threads) ). I fear that this is way to slow. In particular, for each root all children have to be traversed (number of columns) times although once should be enough. Whether an item should be underlined or not should be determined somewhere else. In paintCell only something like
  font.setUnderline( mHasUnreadChildren );
should be done where mHasUnreadChildren is a member variable of HeaderItem.

On Wednesday 16 August 2006 09:59, Ingo Klöcker wrote:
> ------- Additional Comments From kloecker kde org  2006-08-16 15:59 -------
> What's the use case for this wish? Why do you want to know which threads
> contain unread messages if you are not going to read those unread messages?
> If you are going to read them then why don't you make KMail automatically
> open threads containing unread messages? If you see a closed thread
> containing unread messages then you have to open the thread before you can
> read the unread messages. So I don't see the point of not having threads
> with unread messages opened already by KMail. And if you are not interested
> in threads then mark them as ignored. Then they won't be opened even if
> they contain unread messages.


"Why do you want to know which threads contain unread messages if you are not 
going to read those unread messages?"

This question presumes, incorrectly, that users do *not* intend to read unread 
messages. Alert the user by highlighting the thread and let him/her decide.

"If you are going to read them then why don't you make KMail automatically 
open threads containing unread messages?"

Because having KMail automatically expand these threads defeats the whole 
purpose for having a collapsed view, which is to provide users a convenient 
'overview' of the in-box's contents.

"If you see a closed thread containing unread messages then you have to open 
the thread before you can read the unread messages."

This is the point... I prefer to selectively expand threads that contain 
unread messages in whatever order I and my schedule or mood dictate. I don't 
want that decision being made for me automatically, in advance.

"... if you are not interested in threads then mark them as ignored."

My interest in a thread, or lack thereof, has nothing to do with this feature 
request. The 'ignore' flag is a completely different and unrelated feature. 
IOW, it serves an entirely different purpose.

And thanks for staying on top of this!

There is a "Threads closed by default" option. For it to be at all useful two changes are needed -- this bug and bug 117543. Not indicating if there are unread messages in collapsed threads is unhelpful. Not being able to use "Next unread" to find them is even worse.

For a more concrete use case, I don't like the automatic expansion of threads with unread messages. I want the overview that Carl mentions. Further, I don't always want to read the messages in order. The underlining tells me which threads have new messages.

About the implementation: You're probably right that it's better to add a new member variable and update it as needed.

This issue is still present in the latest kmail from KDE 4.1 Beta2

I just came here to report this bug myself and came across this rather old bug that seems to fit the bill.

Anyway, I can report that it is still a problem in kde 4.3.2, kmail version 1.12.2. I'm looking at a mail list now with three unread mails shown against the folder but I only see two of them, the other is "lost"... "Next unread message" doesn't find it either. Poor message...

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.

(In reply to comment #19)
> 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.

This feature request is 10 yrs old and was never closed as invalid. That means, it is a valid request.

Wouldn't it make sense to carry forward such valid requests to kmail2, instead of closing?

Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.