Bug 221345

Already implemented. Go to Setup digiKam Misc page and turn off right option...

Gilles Caulise

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.

Nothing news : but "Scan for new items at startup." is that you need...

Gilles

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.

Start is not processed until you press Enter. CTRL+F show search page that all

Gilles Caulier

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

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.

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

There is a timer at 800ms

really Marcel ? well, here it doesn't work because search is started immediately.

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

Gilles

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?

No, timeout() is the problem I think.

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).

Marcel,

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

Gilles

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

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.

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.

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.

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.

Well, yeah, search action with empty search field is not something what you'd expect (and is quite slow).

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.

(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.

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

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?

Tenno,

This file still valid using digiKam 2.x serie ?

Gilles Caulier

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.

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.

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.

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

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

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

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

Really, I don't understand what will change ... will be "autosearch" selectable by user?

You can disable the auto search and the search will now start only when you hit the Enter key.

Maik

Fantastic!!! That's what I thought it should be.

THANK YOU