Version: 1.4.2 (using 4.2.2 (KDE 4.2.2), Debian packages) Compiler: cc OS: Linux (x86_64) release 2.6.29-toi3 I sort feed articles to that the top is the most recent one and start reading from the older as I press '-' (next unread article). If the article list is long as you approach to top article, akregator automatically scrolls down the article list so you can go on reading the hader of the more unread recent ones. When article list nears end the scroll stops. When this happens you should see all unread articles remaining. This was true on akregator3 but it is not on akregator shipped with kde4.2.2. Currently the list scrolls to more recent unread but one which remains hidden unless you explicitly scroll down the article list. Find attached some screenshots.
Created attachment 33253 [details] Article list approaching the end of the unread articles.
Created attachment 33254 [details] Article list showing the most recent article not seen before.
I can confirm the problem with akregator 1.4.2 on an up to date fedora 10.
I can confirm this bug with ubuntu/karmic and kdesvn. I think it is a bug in Qt. This tiny patch fixes it for me. Does this have side effects for other programs? --- qt4-x11-4.5.2.orig/src/gui/itemviews/qtreeview.cpp 2009-07-07 08:26:59.000000000 +0200 +++ qt4-x11-4.5.2/src/gui/itemviews/qtreeview.cpp 2009-07-07 08:11:34.000000000 +0200 @@ -1129,7 +1129,7 @@ if (y < 0 && item < itemLocation) ++item; // end up half over the bottom of the area - if (item >= 0 && item < itemLocation) + if (item > 0 && item < itemLocation) ++item; verticalScrollBar()->setValue(item); }
This is a better fix, because the selected item will always stay in the middle. - if (item >= 0 && item < itemLocation) + if (hint != PositionAtCenter && item >= 0 && item < itemLocation - 1)
Hi. I think this is fixed somehow on 4.4.2. Could anyone confirm? Thanks.
Yes, this bug has been fixed with Qt 4.6. It can be closed.
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of akregator (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.