Bug 105696

Items (in the plural form), as multi-selection has already been introduced in SVN.

On Sunday 15 May 2005 11:40, Eckhart Wörner wrote:
> ------- Items (in the plural form), as multi-selection has already been
> introduced in SVN.


I'm running svn trunk; so I know that; 
Unfortunately your comment has no relevance on the status combo and thus 
none on this bug report.
Note that akregator has just one 'selected' item at a time; the one showing 
in the preview area (named the html view in the original bugreport).

Cheers

> I'm running svn trunk; so I know that;

Not the latest, otherwise you would have known that there is no "new & unread" status option anymore ;-)

I added my first comment because:
> I would really like to see that the selected item in the listview will stay 
> whatever the status, and keep it selected like it is now.

The problem is: If you have more than one article selected and then apply a filter, should those "other" selected articles also be shown without respect to the filter, or should the selection be removed from them?

SVN commit 414566 by osterfeld:

follow the behavior of other search bars and reset filters when selecting another node
BUG: 105696


 M  +2 -0      trunk/KDE/kdepim/akregator/src/akregator_view.cpp  
 M  +7 -4      trunk/KDE/kdepim/akregator/src/searchbar.cpp  
 M  +1 -0      trunk/KDE/kdepim/akregator/src/searchbar.h  


--- trunk/KDE/kdepim/akregator/src/akregator_view.cpp #414565:414566
@@ -714,6 +714,8 @@
 
     m_tabs->showPage(m_mainTab);
 
+    m_searchBar->slotClearSearch();
+    
     if (m_viewMode == CombinedView)
         m_articleViewer->slotShowNode(node);
     else
--- trunk/KDE/kdepim/akregator/src/searchbar.cpp #414565:414566
@@ -132,10 +132,13 @@
                 
 void SearchBar::slotClearSearch()
 {
-    d->searchLine->clear();
-    d->searchCombo->setCurrentItem(0);
-    d->timer.stop();
-    slotActivateSearch();
+    if (status() != 0 || !d->searchLine->text().isEmpty())
+    {
+        d->searchLine->clear();
+        d->searchCombo->setCurrentItem(0);
+        d->timer.stop();
+        slotActivateSearch();
+    }
 }
 
 void SearchBar::slotSetStatus(int status)
--- trunk/KDE/kdepim/akregator/src/searchbar.h #414565:414566
@@ -50,6 +50,7 @@
         int delay() const;
 
     signals:
+        /** emitted when the text and status filters were updated. Params are textfilter, statusfilter */
         void signalSearch(const ArticleFilter&, const ArticleFilter&);
 
     public slots:

I think you closed the wrong bug; committed fix had nothing to do with this bug. Reopening since this is not yet addressed.

Please re-evaluate.

kmail has the same behaviour

I have some problems with this: 

1) The user could think that the currently selected article(s) match(es) his search criteria, wondering why he can't find his search term in it
2) A non-empty article list conflicts somewhat with the "No matches" box shown when no article matches. 

I think a better fix for this would actually be to completely deselect the current article if it doesn't match the filter; it should disappear from the article contents view as well.

The current behaviour in akregator (from master) is just like Alex Merry said. Should this bug be closed?

Lê Hoàng Phương ,  I can give you bug closing permission.  do you want that?
-Allen

Thank Allen. It would be very convenient to have that permission.

Lets close this one now :)