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.
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.
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...
Works great in KDE 3.4.2. Thanks a lot. I'm closing this bug.