Bug 109244

Summary:	selection of an article takes too much time
Product:	[Applications] akregator	Reporter:	Till <kdebugsystem>
Component:	general	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED WORKSFORME
Severity:	normal
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
Latest Commit:		Version Fixed In:

Description Till 2005-07-18 10:24:08 UTC

Version:            (using KDE KDE 3.4.1)
Installed from:    Debian testing/unstable Packages

When clicking on an unread article, it takes a lot of time until that article gets selected.
I guess, the article gets fetched first, before the list view (the selection) is updated. What about the following behaviour, when clicking on an article:
1. update selection
2. fetch article
3. update content area to display selected article (maybe put something like "loading..." in the content area before)
4. mark article as read.

Of course loading an article would have to be done in a background thread. IMHO the described behaviour would improve responsiveness and with that usability.

Comment 1 Frank Osterfeld 2005-07-18 10:49:56 UTC

I guess the article list contains a lot of articles when it is that slow? Please try feeds with only a small number of articles and compare.

In 3.4 branch, the whole list is recreated when an article changes.
This should be fixed in SVN HEAD (i.e. kdepim 3.5), where only the changed articles are updated. 
In 3.4 branch it still repaints the whole list, but it should be better in 3.4.2 than in 3.4.1, as repainting big lists got _much_ faster.

Comment 2 Till 2005-07-19 13:59:28 UTC

You are right. Feeds with smaller numbers of articles react significantly faster.
I will check with KDE 3.4.2 when it is available (for my platform) and will either close this report or add more information.
Maybe I also have a look at a current Akregator earlier, if I have time...

Comment 3 Till 2005-09-16 14:15:36 UTC

Works great in KDE 3.4.2. Thanks a lot. I'm closing this bug.