Version: 1.0 (using KDE 3.4.89 (CVS >= 20050314), compiled sources) Compiler: gcc version 3.3.5 (Debian 1:3.3.5-8) OS: Linux (i686) release 2.6.10 Clicking an item and then changing search-status I only see items that fit the new description (for example 'new & unread'). This change may remove the currently selected item from the listview while the html-view still shows the summary of the formerly selected item. Keeping the selected item as the active one is a good idea, less change means less confusion. 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. To reproduce; - go to a feed with some items in them - select an unread item - change status to 'new&unread' notice how the current item is removed from the list. I expected that item to be visible and selected.
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 :)