Bug 117543

Summary:	Go to next/previous unread won't find unread in collapsed threads
Product:	[Unmaintained] kmail	Reporter:	Magnus Holmgren <holmgren>
Component:	general	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	lex.lists, qpadla
Priority:	NOR
Version:	1.11.0
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	New findUnread (sketchy) Make readSortOrder() (re)use the very useful findUnread() method

Description Magnus Holmgren 2005-12-02 23:05:21 UTC

Version:           1.8.2 (using KDE KDE 3.4.2)
Installed from:    Debian testing/unstable Packages
OS:                Linux

It appears that when threading mode is enabled and there are unread messages in collapsed thread(s) (either because said thread(s) have been manually collapsed or because one prefers not to automatically  expand threads with unread messages), "Go to next unread message" and "Go to previous unread message" simply refuses to expand the collapsed thread(s), instead skipping ahead to the next unread visible message.

It becomes even sillier when there are no other unread messages except those in the collapsed thread(s), and Kmail is configured to start looking again from the beginning of the current folder. Kmail will then repeatedly ask if I want to go to the next unread message in <current folder>, but get nowhere.

Comment 1 Magnus Holmgren 2006-03-29 13:11:19 UTC

(The version I'm looking at now is 1.9.1 (KDE 3.5.1).)

This is no wonder as KMHeaders::findUnread() and KMHeaders::findUnreadAux() uses QListViewItem::itemAbove() and QListViewItem::itemBelow() to step through the message list. I have written a new implementation using an iterator. I hope QListViewItemIterator::operator--() isn't as slow as QListViewItem::itemAbove().

I also found a couple of peculiarities (they look like bugs, but it also appears they will never be executed):

In KMHeaders::findUnreadAux():
>    while (item)
>    {
>      msgBase = mFolder->getMsgBase(item->msgId());
>      if (!msgBase) continue;

Looks like an infinite loop should msgBase ever be null.

The code in KMHeaders::findUnread() that forces the thread where the first new or unread message was found to be sorted appears to terminate too early in some cases. It stops when next == item, but item is the item found that is "not necessary the first unread item". When looking for the previous unread message there could be more unread messages in the unsorted branches below.

I don't know if there are any threading issues, but if no unread item is found the first time there doesn't seem to be much point in doing the second pass.

The sorting-enforcing bit would be more elegant using an iterator.

Comment 2 Magnus Holmgren 2006-03-29 13:22:48 UTC

Created attachment 15348 [details]
New findUnread (sketchy)

There is duplicated code because I didn't want to create a new method or change
the signature of an existing one myself.

The two last remarks in my last comment haven't been implemented.

Comment 3 Magnus Holmgren 2006-04-03 15:00:59 UTC

Created attachment 15442 [details]
Make readSortOrder() (re)use the very useful findUnread() method

Appears to be working in all three cases of
GlobalSettings::self()->actionEnterFolder().

Maybe you already had this in mind when findUnread() got its onlyNew parameter?

Comment 4 lexual 2006-10-20 06:34:21 UTC


*** This bug has been marked as a duplicate of 50806 ***

Comment 5 Magnus Holmgren 2006-10-20 08:28:58 UTC

No, I read bug 50806 before filing this bug and found that it was not the same thing. At least this bug wasn't fixed. And it still isn't.

Comment 6 Thomas McGuire 2008-02-27 22:46:29 UTC

*** Bug 151509 has been marked as a duplicate of this bug. ***

Comment 7 lexual 2009-02-23 00:42:05 UTC

Working with kde 4.2. version.