Bah, sorry. I obviously meant: "This is a regression from 3.4.0".

This is intended: We follow KMail here for the sake of consistency. Also, if the user switches feeds and forgets he set the status to something else than "all articles", he might get confused seeing an empty list.
I see that some people might have it set to "unread" all the time. We could add a configuration option for them ("show only unread articles by default")

OK, I understand that. So in my setup above, upon selecting "Feed B", the selector changes to "All articles", and all articles should be shown, right? But read what I wrote (this is with 3.4.1 tarballs):

> Now I select "Feed B", and I see that the Status selector displays "All
> articles" now, yet only unread articles are being shown.
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So there's obviously something wrong. I believed it was the selector (based on the 3.4.0 behavior), but as per your explanation, it's the content pane that is wrong (as per the new desired behavior to match KMail's).

I would reopen the bug for the above reason, but I won't since I can't easily check if it's been fixed in SVN. Please reopen as appropriate, thanks.

Uh, indeed. It's broken in 3.4 branch, but works in HEAD.

Hi Frank,

First of all thanks for your time/effort you put in Akregator. I really appreciate it.

Are you going to backport this and other fixes to 3.4? This is kinda confusing.

The upgrade from Akregator shipped with kde 3.4.0 to Akregator shipped with kde 3.4.1 had some unpleasant side effects;
- Akregator now always opens in the "Welcome to Akregator 1.1.1"-window, used to be the first new/unread message in a feed
- Akregator now always opens with status "All Articles", used to be the the status Akregator closed with (in my case new & unread)
- when changing feeds "Status drop down box" is reset to "All Articles", however the view is still the same as the status selected before (this bug report)

Fortunately I use Gentoo so it's easy for me to switch only Akregator back to the version shipped with kde 3.4.0 (gotta love the split ebuilds). Other people that don't use Gentoo and use Akregator a lot might need to downgrade entire kdepim (or perform a manual installation).

Forgot to mention another side effect after the upgrade to Akregator shipped with kde 3.4.1;
- after Akregator is started selecting new & unread doesn't work anymore, you first need to select new or unread and after that selecting new & unread works again.

>>
Also, if the user switches feeds and forgets he set the status to something else than "all articles", he might get confused seeing an empty list.
<<

Could I suggest a technique that may help alleviate the need for a seperate option? Put a different looking message in the content pane that says something along the lines of "There are no 'New & Unread' articles."

I would be one of the users that utilised a "Always restrict to New & Unread" option, but I don't think it's neccessary to have an option if you remember the setting and use text to explain an empty content pane.

I'll be honest and admit that I was a fan of Akregator, but I've had to stop using it recently as I can't see how to reliably limit my view to "New & Unread" so I have to blunder my way through 136 articles to find the ones I'm after. It's a shame because when it's hooked up to a Wiki that has automated imports it makes a great "Recently Changed" aggregator.

>Could I suggest a technique that may help alleviate the need for a seperate
> option? Put a different looking message in the content pane that says 
> something along the lines of "There are no 'New & Unread' articles." 

Yeah, we have something like this now. A box is drawn saying something like  "no articles match your current filter search".

I am inclined to switch back to the old behaviour for 3.4.2, and add an option like "make filter settings sticky" for 3.5.

I add my view in this bugreport, since it's obviously related.

In KDE 3.4.1, Akregator remembered the filter setting at least when I switched feeds; I only had to manually change it after launch. But in 3.4.2, the filter setting changes back to "All articles" every time I go to another feed. It's extremely annoying since I have many feeds, especially since Akregator is a bit slower than in 3.4.1 when loading a feed...

Thanks for your attention!

3.4.0 did remember the filter settings, 3.4.1 was supposed to reset it, which was broken, as the filters were reset but the "all articles" button was not.
In 3.4.2, it should work as in KMail: filter settings are reset when changing feeds. We decided for this to be consistent with KMail and Knode.
I understand that this annoying if you want to see only unread articles, as there is no convenient way anymore. We will add a configuration option for 3.5.

>It's extremely annoying since I have many feeds, especially since 
>Akregator is a bit slower than in 3.4.1 when loading a feed... 
Slower?? Actually we fixed a bug in the article list code, so the time needed on my box to render the list for "All Feeds" was reduced from from 40 to 4 seconds...
 

I disagree about this consistency thing, but I'm no usability expert. Mails and feeds are not the same kind of things, the usage is very different: mails are personal, addressed to you, and you usually store them and want to see your whole mail box. Feeds are pieces of information you don't want to store for more than a few days and usually you don't read one twice.

This difference, I would think, has a direct impact on the filter setting's behavior. Just my two cents...

As for the speed issue, it's not much. In KDE 3.4.1, displaying the content of a feed was always instantaneous. In 3.4.2, there is a small delay, less than a second. It's mostly independent of the number of messages to display. I have the same delay, whether there are only 5 messages or 200 messages.

Sorry to ask again, but after a few days using KDE 3.4.2, I find it really impossible. This change means that I have to manually change the filter setting several dozen times a day (each time I check for new messages, for each feed), so it's a big usability issue for a very small detail.

Could someone point me to the part of the source code that controls this behavior, please? I'd like to revert that change and recompile Akregator, but I'm not familiar with KDE programming. Thanks in advance.

Created attachment 11995 [details]
disable filter reset on node change

This should do

Thank you very much. The patch was indeed very simple and applied without problem. I rebuilt my RPM package and installed it, now Akregator is usable again with many feeds. :-)

Hi Frank,

Is it possible to post a patch that returns usability from the 3.4.0-version (remember filter when starting up/shutting down, remember filter when changing feeds and make the new & unread filter work again without selecting an other filter first)?

To be honest I agree with Thibaut that making Akregator consistent with kmail/knode has some very unpleasant side effect. This due to the fact that both are different applications with different goals/purposes.

While I'm still being honest, I really think that Akregator in 3.4.0 was one of my favorite apps, but during upgrade in the _stable_ series it became one of my biggest annoyances.

It really makes me wonder if you use this version yourself and how many feeds you have? Do you think the current stable version is usable (with many feeds)?

Maybe you should reconsider your quest for consistency with kmail/knode and ask the usability group for their opinion before continuing.

Just for the record; please consider this post as positive feedback from an Akregator-user.

> Is it possible to post a patch that returns usability from the 3.4.0-version
> (remember filter when starting up/shutting down, remember filter when 
> changing feeds and make the new & unread filter work again without selecting > an other filter first)?

Except for saving filters on shutdown, this should work with the patch above? What do you mean with "make the new & unread filter work again"?

> but during upgrade in the _stable_ series it became one of my biggest annoyances. 

Because of this issue? Or are there other regressions I am not aware of?

>It really makes me wonder if you use this version yourself and how many feeds 
you have? Do you think the current stable version is usable (with many feeds)?

There are some performance-related issues with many feeds in the stable version:

1) slow startup, huge memory consumption. This is improved in SVN, but can't be fixed in the 3.4.x series. (as it needs major changes)

2) slow rendering of the article list: Filling the list with articles, was extremely slow, due to adding the article headers to the list in a stupid way. This fixed in 3.4.2. (from 40 secs down to 4 here)

3) related to 2), if a user has "All Feeds" (or any other folder with many feeds/articles) selected and fetching starts, Akregator eats all your CPU and freezes. This is because every feed fetched causes the article list to be completely cleared and refilled. (e.g. 40 seconds * 40 feeds = 1600 seconds full CPU usage) This should be improved in 3.4.x because of the fix for 2). In SVN, we avoid complete rebuilding of the article list and the problem should be gone there entirely. 
To avoid the problem, never select "All Feeds"...

Ok, this is all performance related. Now to the quick filter. If I understand you correctly, the filter problem has nothing to do with performance (where it shouldn't have a deep impact), but the way you use Akregator to read articles.

Maybe our "usage patterns" differ, so let me describe how I use it (having 88 feeds, with 34213 archived articles in total): 

- I mostly read articles "feed-wise", selecting single feeds and looking what's new. As the new items are usually on top here, I don't need a filter. I just scan the list and sometimes use +/- shortcuts to walk through unread articles. 
And for folders, usually there are too much unread articles, as "show me all unread articles for Folder X" would make sense. I am rarely interested in all the unread items in a folder at once, as there are many relatively unrelated "high-traffic feeds" (CVS commits, wiki changes...) in it. So I prefer to read the items feed-wise.
- Actually I select folders only for searching, and I almost never use the status filter except for listing flagged articles.

On the other hand, I understand that people want to see unread articles only, or see everything unread in one list. As "show me all the new stuff" is a central use case and it should be possible do get that conveniently. I guess this is how you use it?

Some ideas to improve the filtering for new items:

 - make the filter thing configurable.
 - make it possible to sort the article list by status (this was already requested by usability folks)
 - add special nodes like "Unread articles" to the feed list to filter for the state. This would be more intuitive than selecting "all feeds" and setting the quick filter. The drawback is that you can't select specific folders or feeds this way.

Hi Frank,

First of all thanks a lot for your reply. I think it proves you have a open mind and are open for suggestions.

Let me explain a little bit more about my usage pattern;
As you know most feeds have a limit on the number of articles you get when you contact their site. Because of this I open Kontact (thus Akregator) regularly to make sure I don't miss to many articles. When I have the time/mood I will go through the articles and select the ones I think that are interesting. Because of this pattern I'm only interested in New & Unread articles. I'm not interested in read articles, only unread or only new articles.

In 3.4.0 my preferences where saved, but later versions removed that feature.

> What do you mean with "make the new & unread filter work again"? 
When I start Kontact and select feeds the status is always set on "All Articles" in the dropdown menu. I have 4 other options in the dropdown menu (New & Unread, New, Unread and Keep Flag Set). When I select New & Unread immediately nothing happens. I first need to select New or Unread (both filters do exactly that) after that when I select the New & Unread the filter works.

>> but during upgrade in the _stable_ series it became one of my biggest annoyances. 
> Because of this issue? Or are there other regressions I am not aware of?
For me there is another regression (I will come to that later) but that doesn't annoy me that much.
What I think is really annoying that the filter settings (All Articles) are being enforced on the user. This was introduced in 3.4.1.

When I select another feed the filter is reset again to All articles (but not the initial view) so before I can type something in the search bar I have to change it back to New & Unread again (by clicking a dropdown menu twice).

The other regression is performance, but that isn't something that changed in the stable releases (as far as I can tell). Like I said before I always use Kontact, sometimes I only want to read my mail. With a lot of feeds/articles I have to wait until Akregator is finished with starting up before I can read my mail. I don't know if this is the problem of Akregator or the Kontact framework. But from my point of view individual Kontact-components shouldn't block the others when starting up. I was able to workaround this by setting the auto-delete-articles to a low value.

I hope you understand what I mean. If you want I can meet you on IRC for better/more information/explanation and/or give you access to my box so you can see it for yourself.

I just wanted to add that I also have the problem with the "New & unread" button that doesn't work. It's minor since I only have to switch to "Unread" and back to "New & unread" once, and then it works correctly as long as I don't quit Kontact. Once again, I'd like to know if someone could post a small patch here. Thanks in advance. :-)

I don't know whether it's really helpful, but once Akregator behaves correctly from a usability point of view, I'm willing to merge the patches that were necessary and post them here, where anyone able to recompile Akregator can find them. In the meantime, I'm OK to test any patch related to the problem. :-)

> But from my point of view individual Kontact-components shouldn't block the others when starting up. I was able to workaround this by setting the auto-delete-articles to a low value.

Akregator is only loaded at startup when it was the active part when you closed it (because it will be selected then when starting).

> I just wanted to add that I also have the problem with the "New & unread" button that doesn't work. It's minor since I only have to switch to "Unread" and back to "New & unread" once, and then it works correctly as long as I don't quit Kontact.

I can't reproduce this with 3.4.2. Is "New&Unread" the only option that does not work for you? Do the others work correctly?

Le Mercredi 3 Août 2005 19:41, Frank Osterfeld a écrit :
> I can't reproduce this with 3.4.2. Is "New&Unread" the only option that
> does not work for you? Do the others work correctly?


  Yes, it's the only one. I need to switch to another options, and then back 
to this one, for it to work.
  I don't know if it's related, but it's also the only choice in the list that 
doesn't have an icon. The other four have a proper icon.
  I attached a snapshot, I hope it's the correct way to send a file here.


Created an attachment (id=12068)
akregator.png

Sorry, I forgot to add that the screenshot is in French. "New and unread" is "Nouveau et non lu", "All articles" is "Tous les articles".

Same over here, "New & Unread" doesn't have an icon.

The bug has not to do with the missing icon, which is just not set in the code, no bug here.

To have "New & Unread", "New" (showing new but not unread) and "Unread" (showing unread but not new, very strange option) does not make sense anyway, we replaced it in 3.5 branch by "Unread" (showing unread+new, as a new article is also unread) and "New".

And, happy news, I finally decided to revert the behaviour in the 3.4 branch.

First off, I love akregator!.. just wanted to get that out there :)

And reverting the behavior in the 3.4 branch is happy news indeed!  Thanks!

Now onto my thoughts (just my opinion/thoughts here on this bug):

The provided patch made akregator usable again, but it was an absolute PAIN to get it in on my Gentoo system.. basically I had to open the kdepim, edit the file, re-bzip the kdepim put it back in my /usr/portage/distfiles, ebuild digest the sucker then re-emerge akregator, after all of that was done, I had to replace the kdepim with the original so that anything else based on that file would compile ok.. 

All of this is said to make a point:

There HAS to be a better way to deliver, test, implement changes to akregator than just waiting for the next kde version to come out.  For users of KDE 3.4.2, akregator is all but unusable as is evidenced by this thread.  akregator is a GREAT program, but it seems that some usability is still being worked out.. for this reason, builds should be coming faster than once every 2-3 months.  Betas, Release Candidates, etc. would help work out ALL of these problems before a major release in the kdepim file.  http://akregator.sourceforge.net seems to be no longer maintained, especially the downloads, and downloading all of the kdepim from subversion and just compiling akregator seems next to impossible (or at least a major PITA).  Just my two cents on the subject :)  Thanks again for a great program! (the best RSS reader in Linux, and goodness knows I have tried them all!)

I agree that some entries could be merged and what you're proposing seems reasonable to me. I'm looking forward to 3.4.3.
Thank you for your time and attention, Frank. :-)

> out.. for this reason, builds should be coming faster than once every 2-3 
> months.  Betas, Release Candidates, etc. would help work out ALL of these #
> problems before a major release in the kdepim file.

Well, as akregator is part of kdepim, there won't be official releases outside of kdepim anymore, as supporting kdepim releases and standalone builds is a PITA and would confuse users (and most likely break their setups when installing both in parallel). We could offer SVN snapshots for the brave, but that'd need a volunteer who creates them.

To create an Akregator tarball, you need to rip out Akregator subdir from kdepim, take the used parts of libkdepim (but not all, otherwise you have 3/4 of kdepim in your dependencies), move kontact plugin to akregator subdir... and adjust Makefiles. Scripting it didn't work out too well (it needed manual adjustment all the time), and nobody in the team is willing to spend his nights on that.

> http://akregator.sourceforge.net seems to be no longer maintained

It will die long-term, and the info will go to the KDEPIM sites. For akregator-specific news, there is the akregator blog.

> especially the downloads, and downloading all of the kdepim from subversion
> and just compiling akregator seems next to impossible (or at least a major
> PITA).

See? ;-) 
The easiest way to test the development version is to compile whole kdepim, install it to its own prefix, set KDEDIRS=$prefix:$KDEDIRS, PATH=$prefix/bin:$PATH, and run akregator.

> Just my two cents on the subject :)  Thanks again for a great program! (the 
> best RSS reader in Linux, and goodness knows I have tried them all!)

Thanks, and thanks for feedback :)
For further discussion I suggest to use the mailing lists, as this is not exactly bug-related anymore ;-)

> And, happy news, I finally decided to revert the behaviour in the 3.4 branch.

Are you going to revert it to the 3.4.0- or 3.4.1-behaviour?


@Bryan (off-topic)
A Gentoo-related tip;
You never need to modify a distfile, just copy the ebuild for Akregator in your overlay and add an epatch-statement in the ebuild. Within 2 minutes you can emerge a patched Akregator and it doesn't have any (negative) effect on other ebuilds.

> Are you going to revert it to the 3.4.0- or 3.4.1-behaviour? 
3.4.0. I'd say 3.4.2 is equal to 3.4.1 behaviour but less broken, so it would not make sense to revert it to 3.4.1. 

>> Are you going to revert it to the 3.4.0- or 3.4.1-behaviour? 
> 3.4.0

Yahoo, thanks a lot!

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

marked the wrong one as dupe...

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

SVN commit 453709 by osterfeld:

revert quick filter behaviour back to 3.4.0 style, don't reset quick filter when switching feeds
CCBUG: 106348


 M  +6 -9      akregator_view.cpp  


--- branches/KDE/3.4/kdepim/akregator/src/akregator_view.cpp #453708:453709
@@ -248,9 +248,6 @@
     m_feedSplitter->setSizes( Settings::splitter1Sizes() );
     m_articleSplitter->setSizes( Settings::splitter2Sizes() );
 
-    m_searchCombo->setCurrentItem(Settings::quickFilter());
-    slotSearchComboChanged(Settings::quickFilter());
-
     switch (Settings::viewMode())
     {
         case CombinedView:
@@ -269,6 +266,9 @@
     m_tabs->setTitle(i18n("About"), m_mainTab);
     m_displayingAboutPage = true;
     
+    m_searchCombo->setCurrentItem(Settings::quickFilter());
+    slotSearchComboChanged(Settings::quickFilter());
+
     m_fetchTimer=new QTimer(this);
     connect( m_fetchTimer, SIGNAL(timeout()), this, SLOT(slotDoIntervalFetches()) );
     m_fetchTimer->start(1000*60);
@@ -843,7 +843,7 @@
     
     m_tabs->showPage(m_mainTab);
 
-    slotClearFilter();
+    //slotClearFilter();
 
     if (m_viewMode == CombinedView)
         m_articleViewer->slotShowNode(node);
@@ -1344,11 +1344,8 @@
 
 void View::slotSearchComboChanged(int index)
 {
-    if (index != Settings::quickFilter())
-    {
-        Settings::setQuickFilter( index );
-        updateSearch();
-    }
+    Settings::setQuickFilter( index );
+    updateSearch();
 }
 
 // from klistviewsearchline

SVN commit 457084 by osterfeld:

fix the "reset quick filter" issue. It's configurable now.
BUG: 106348


 M  +14 -0     akregator.kcfg  
 M  +27 -4     akregator_view.cpp  
 M  +4 -1      searchbar.cpp  
 M  +53 -36    settings_advancedbase.ui  

Akregator 1.2.4 with KDE 3.5.4 and Kubuntu 6.06 does that again. If I choose status only unread articles and then swithch to another feed (and then again back), it shows all articles.

Did you uncheck "Reset search bar when changing feeds" in Configure Akregator->Advanced?

As it seems the "Reset search bar when changing feed" option has disappeared again which leaves us once again with the same brain death behavior as kmail. I do hope this is a regression as I really don't understand why people like to waste time on finding new articles between all the old stuff (even worse with kmail and mailinglists..)

Please give me/us back this option.. 

Set to not reset filters for 4.1.3, with the old UI option in trunk (4.2)