After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 351929 - Cannot clear Advanced Search result in Contacts
Cannot clear Advanced Search result in Contacts
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Contacts
2.8.x (obsolete)
Other Linux
: High normal
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2006-08-18 14:38 UTC by Matthew Barnes
Modified: 2013-09-13 00:52 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Matthew Barnes 2006-08-18 14:38:20 UTC
Forwarding this bug from downstream.
Confirmed that it still exists in Evolution 2.7.91.
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202556


Description of problem:


Version-Release number of selected component (if applicable):
evolution-2.7.91-2

How reproducible:
always

Steps to Reproduce:
1. Launch Contacts-Evolution 
2. Select ''Personl'' address book (make sure there are several Contacts in it)
3. Click menu Search -> Advanced Search (Advanced Search window launches)
4. Type search name and add criteria -> click OK
   (Search result are displayed)
4. Click Clear in the search bar

  
Actual results:
Advanced Search window launches, and cannot clear search result

Expected results:


Additional info:
Comment 1 André Klapper 2006-08-20 11:39:03 UTC
confirming - this blocks using the search for a second time.
Comment 2 Matthew Barnes 2006-08-20 15:23:12 UTC
My investigation of this has revealed a puzzling detail in the source code.

In widgets/misc/e-search-bar.[ch] it looks as though some preparation for a "search_cleared" signal was made, but the signal was never actually defined.  Instead, when the "Clear Search" button or "Search -> Clear" menu item is selected, the "search_activated" signal is emitted.  This signal is emitted for several other types of search-related events too.

This makes it difficult for subclasses to determine whether the user wants to clear the search when the signal is received.  In the case of the address book, there seems to be no way for the "search_activated" handler to tell whether the user just selected the "Advanced Search" option or whether the user just clicked the "Clear Search" button and the "Advanced Search" option happened to be selected from a previous search.  Hence the malfunction described above.

It seems to me that the cleanest solution would be to define the "search_cleared" signal in e-search-bar.c and emit it when appropriate.  Subclasses would have to be modified to connect to it and handle it appropriately.  But it may simplify the logic a bit, and the subclasses that I've looked at could use some simplification.
Comment 3 Srinivasa Ragavan 2006-08-20 16:35:14 UTC
true. But by design of the old search code, "clear search" is nothing but a signal for search for "" :) Ive fixed a lot of bugs in search and I have this working now. Will commit it for tomorrow's release. Ive removed the recursively popping up of advanced dialog which seems to fix this issue for me.
Comment 4 Matthew Barnes 2006-08-22 18:35:29 UTC
Evolution 2.7.92 fixes the problem.  Thanks!