Bug 221345 - Do not process search immediately when enter text to query
Summary: Do not process search immediately when enter text to query
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Searches-Engine (show other bugs)
Version: 1.0.0
Platform: Debian testing Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-05 09:34 UTC by Tenno Seremel
Modified: 2018-08-15 21:54 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tenno Seremel 2010-01-05 09:34:48 UTC
Version:           1.0.0 (using KDE 4.3.2)
OS:                Linux
Installed from:    Debian testing/unstable Packages

It would be useful to have an option to turn off search autostart since with large collections it's not always a good idea to start searching until you complete your query.

Sometimes I'm not writing it right away and digiKam thinks it can search already (which is not always the case).
Comment 1 caulier.gilles 2010-01-05 11:00:33 UTC
Already implemented. Go to Setup digiKam Misc page and turn off right option...

Gilles Caulise
Comment 2 Tenno Seremel 2010-01-05 11:16:52 UTC
It is? I can't seem to find it.

There are only 4 settings in the Miscellaneous Settings:

* Confirm when moving items to the trash;
* Do not confirm when applying changes in the right sidebar";
* Show splash screen at startup;
* Scan for new items at startup.

Was it implemented recently? digiKam's version is shown as 1.0.0~beta4-2 in aptitude.
Comment 3 caulier.gilles 2010-01-05 11:25:05 UTC
Nothing news : but "Scan for new items at startup." is that you need...

Gilles
Comment 4 Tenno Seremel 2010-01-05 11:57:59 UTC
Aah... I wrote it way too ambiguous. I'm talking about search field. The one you can get via ctrl + F while the program is already loaded.

i.e. I want an option so digiKam will wait until I press Enter before starting search.
Comment 5 caulier.gilles 2010-01-05 12:30:11 UTC
Start is not processed until you press Enter. CTRL+F show search page that all

Gilles Caulier
Comment 6 caulier.gilles 2010-01-05 12:31:38 UTC
Ok, i understand. CTRL+F show search page + last search processed before. You don't want to see last processed search. Question : why ?

Gilles Caulier
Comment 7 Tenno Seremel 2010-01-05 12:59:00 UTC
Umm… no, previous searches are fine (if that's what you talking about).

When you type something in search field digiKam starts searching automatically as soon as you don't type any letters for some amount of seconds (timeout so to speak). i.e. open search field type 'a' (without quotes). Wait. You'll see.

I want to have an option to stop it from doing so. With large collections when you write 1 letter/short word and make a pause for some reason it's a little bit annoying — disc thrashing, response time and all.

Option should be off by default of course.
Comment 8 caulier.gilles 2010-01-05 13:31:50 UTC
No need an option for that. Using a timer is enough. Like this it lets time for you type more than one character before to process search. Usually 500 ms is fine.

I also notified that in search text field, focus is lost when process is done.

Marcel, what do you think about ?

Gilles
Comment 9 Marcel Wiesweg 2010-01-05 21:53:36 UTC
There is a timer at 800ms
Comment 10 caulier.gilles 2010-01-06 09:33:21 UTC
really Marcel ? well, here it doesn't work because search is started immediately.

I don't take a look in code yet (:=)))

Gilles
Comment 11 Marcel Wiesweg 2010-01-06 19:49:38 UTC
searchtabheader.cpp:
271
    d->keywordEditTimer = new QTimer(this);
    d->keywordEditTimer->setSingleShot(true);
    d->keywordEditTimer->setInterval(800);
    
    connect(d->keywordEdit, SIGNAL(textEdited(const QString &)),
            d->keywordEditTimer, SLOT(start()));

    connect(d->keywordEditTimer, SIGNAL(timeout()),
            this, SLOT(keywordChanged()));

    connect(d->keywordEdit, SIGNAL(editingFinished()),
            this, SLOT(keywordChanged()));

void QLineEdit::editingFinished ()   [signal]
This signal is emitted when the Return or Enter key is pressed or the line edit loses focus. ...

Maybe editingFinished is too early for you?
Comment 12 Johannes Wienke 2010-01-06 20:09:17 UTC
No, timeout() is the problem I think.
Comment 13 Tenno Seremel 2010-01-06 21:07:12 UTC
Maybe it's prossible to wrap this timer creation in some kind of "if(enabled)" and do not create it at all if user says so? (I'd like to have an option like that if it's not obvious yet).
Comment 14 caulier.gilles 2010-01-07 13:37:00 UTC
Marcel,

It doesn't work here because when you change something in text field, search is processed. I never use Enter to validate.

Gilles
Comment 15 Marcel Wiesweg 2010-01-07 18:06:54 UTC
Here, when I type a letter in the line edit field and have a breakpoint set on keywordChanged(), this slot is activated at a distinctly later time (800ms is a good fit) by the timer, timerSourceDispatch() etc. in the backtrace.

If that is not the case for you, there are two possibilities:
1) something is setting off the timer before you actually type
2) it's not the timer triggering keywordChanged(), but the other connected signal, editingFinished(), which is a direct connection to SLOT(keywordChanged()), no through the timer
Comment 16 Johannes Wienke 2010-01-07 20:51:38 UTC
I think this is a complete misunderstanding. To my mind, what Tenno wants is that the search is _not_ triggered before he presses enter. This would only be the case if the timer is removed or disabled since the timer calls the search method every time the text is changed in any way.
Comment 17 Johannes Wienke 2010-01-07 20:57:49 UTC
One more thing about this: right now, if you first enter a search text, wait for the search to start and then empty the search text, the whole database is returned as results for the new search that's initiated. This is definitely a performance problem. So we must not search for empty queries.
Comment 18 Marcel Wiesweg 2010-01-07 21:17:02 UTC
Yes Johannes, your second comment is right. I think Tenno has filed a second bug for this.

About the timer, I was mostly referring to Gilles' comments #8 and #10. Looking at comment #7, you're right, that's not what this bug is about.

Now to the original request:
All other search bars in digikam provide "live" search. If this one now requires to press Enter, that's different behavior. Additionally we would have to add a button "Search" which would be cluttering the interface.
For me, the real problem is the loss of focus. That's a bug.
Additionally, we can increase the timeout a bit.
Comment 19 Johannes Wienke 2010-01-07 21:44:00 UTC
I don't think disabling the automatic search this is a consistency problem. All other searchbars are used in direct combination with lists. Their purpose is completely different and there appearance also. For those searchbars you see the list of possible results before you execute the search. Here, the situation is the complete opposite. You only see results if you started a search - one way or the other, but you have to do manual work to see something. That's why this appears different.
Comment 20 Tenno Seremel 2010-01-07 21:52:42 UTC
Well, yeah, search action with empty search field is not something what you'd expect (and is quite slow).
Comment 21 Tenno Seremel 2010-01-07 21:55:34 UTC
If consistency is really a problem it's possible (when this mode is enabled) to write somewhere "Press Enter in the search field to start seach" or something like that.
Comment 22 Dmitry Khlystov 2010-01-07 22:31:48 UTC
(In reply to comment #18)
> All other search bars in digikam provide "live" search. 

There should be a difference between 'search field' and 'filter fields'. Actually all other search fields are filter fields.
Comment 23 Johannes Wienke 2010-01-07 22:50:31 UTC
SVN commit 1071359 by jwienke:

do not search for empty keyword string

BUG: 221343
CCBUGS: 221345

 M  +2 -1      NEWS  
 M  +1 -1      utilities/searchwindow/searchtabheader.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1071359
Comment 24 Tenno Seremel 2010-06-07 13:42:27 UTC
Is it just me or search with empty search field returned in 1.2?

1. Go to search tab & type some letters
2. Go to Calendar tab
3. Press Ctrl + F

Digikam will switch to search tab and search field become blank.

Should I report a separate bug?
Comment 25 caulier.gilles 2011-12-15 12:54:47 UTC
Tenno,

This file still valid using digiKam 2.x serie ?

Gilles Caulier
Comment 26 Tenno Seremel 2012-06-25 12:21:22 UTC
Ok, I've updated to Debian testing and in Digikam 2.6 original problem still persists. I type 'z' in a search field, make a short pause and Digikam starts searching. Which is horrible, because I have quite large collection. It started thrashing my HDD.

Then I've typed two more letters, which lead to empty result, but disk trashing still goes on for a few minutes after that (reading 5~7 MB/s according to KDE's system monitor).

It does not dump all my collection into result if I enter empty string, though. Which is a plus.
Comment 27 Marcel Wiesweg 2012-06-25 18:03:42 UTC
How large is quite large?
Please rule out thumbnail creation as reason for the disk activity. Digikam will see to create thumbnails for all displayed pictures.
For me, even with a large search result, digikam is completely responsive any time.
Comment 28 Tenno Seremel 2012-06-25 19:19:47 UTC
About 13 GB (19607 files).

Hmm, well, thrashing might indeed be thumbnails as it does not happen if I type that one query again, but happens with a newer one. But I'm pretty sure I already had them before, unless newer version decided it needs them different, oh well, whatever. Shouldn't it stop creating thumbnails which aren't going to be displayed now, though?

Nonetheless, this bug wish is about an option to stop search from starting automatically... Unless I missed it, it does not exist.
Comment 29 caulier.gilles 2015-05-15 22:20:10 UTC
Maik,

This file about search tool and autostart search when enter text will be easy to implement as optional. There is a timer to wrap as explained in comments by Marcel.

Gilles
Comment 30 caulier.gilles 2016-11-26 09:51:05 UTC
*** Bug 338180 has been marked as a duplicate of this bug. ***
Comment 31 Maik Qualmann 2018-07-02 13:20:46 UTC
*** Bug 396092 has been marked as a duplicate of this bug. ***
Comment 32 Maik Qualmann 2018-07-06 19:55:32 UTC
Git commit d77cf9bbbda0152a340e7b7977328a70aba863fb by Maik Qualmann.
Committed on 06/07/2018 at 19:54.
Pushed by mqualmann into branch 'master'.

add autostart action to the right button context menu from the search edit field
FIXED-IN: 6.0.0

M  +2    -2    NEWS
M  +49   -2    core/utilities/searchwindow/searchtabheader.cpp
M  +1    -0    core/utilities/searchwindow/searchtabheader.h

https://commits.kde.org/digikam/d77cf9bbbda0152a340e7b7977328a70aba863fb
Comment 33 Rafael Linux User 2018-08-15 21:01:42 UTC
Really, I don't understand what will change ... will be "autosearch" selectable by user?
Comment 34 Maik Qualmann 2018-08-15 21:10:05 UTC
You can disable the auto search and the search will now start only when you hit the Enter key.

Maik
Comment 35 Rafael Linux User 2018-08-15 21:54:51 UTC
Fantastic!!! That's what I thought it should be.

THANK YOU