probably a regression caused by this commit :

ID: 02eab49b2de51c31fe46a0d9501327b579b3648e
Added by Frank Reininghaus 7 days ago

Increase the timeout in KItemListKeyboardSearchManager to 5 seconds

The previous timeout [QApplication::keyboardInputInterval()] was too
short to do a multi-letter search for users who do not type extremely
fast.

https://projects.kde.org/projects/kde/kde-baseapps/repository/revision?rev=02eab49b2de51c31fe46a0d9501327b579b3648e

Sorry, I just checked... it's not really a bug... but 5 seconds... maybe a little bit too long?

Or "backspace" should clear the last typed letter.

The best would be to let the text appear in the statusbar as an textedit box or something (but a little bit more integrated same background as status text)

When I committed this change, I thought that increasing the timeout to 5 seconds (the same value used by Nautilus) would improve usability because there were complaints about the previous timeout value being too small, but now I see that it was probably not a good idea to do this without providing some visual feedback about the search.

I think Christoph's suggestion makes sense, however, Backspace currently triggers the "Back" action. Maybe one could remove the last typed letter if the search string is not empty and go back if there is no search string left?

Additionally (or alternatively), one could cancel the search when Escape is pressed. Nautilus actually does both of the above things (Backspace triggers the "Up" action there if there is no search string).

I'll also think about how we could implement the visual feedback (something like the line edit shown by Nautilus) and discuss this with Peter, but I think that this is not suitable for a bug fix (i.e., 4.8.x) release.

As long as we don't have a visual feedback for the timeout I'd suggest that for the 4.8.x release we just decrease the timeout again, but still keep it above the original 0.4 seconds. My gut feeling would chose something around 1 to 1.5 seconds...

Fixing the related bug 297488 might be nice for 4.8.x, but if we decrease the timeout to 1 to 1.5 seconds it might not be mandatory I'd say.

By the way, I thought all "non-character" key can be used to clear the search string. I first reaction is to try press Left and Right and see is search buffer reset or not.

@Peter: I agree that 1 second might be a good compromise. If there are no objections, I'll do that and inform the packager's mailing list so they can include that in their 4.8.2 packages if they consider the issue important enough.

@Weng Xuetian: I think it would not be good to make any non-character key abort the search:
If we are going to provide a Nautilus-like line edit in the future, one would expect that the left and right arrow keys will move the cursor in the line edit, so we would have to change the behaviour of these keys again. But making at least Escape cancel the search seems quite future-proof to me.

@Frank Reininghaus 
For this, I think move cursor is a bad idea.
Move cursor is not a usefull case, since people can still use backspace to fix there error. Left and right should always use to move the focus on the selected item. If there is no blink cursor, people will not think left and right can be used to move cursor.

There is a bad case in gnome-shell, gs overlay search field is kinds of line edit, so left and right can be used to move cursor, but how to navigation among different item? the item is list by horizontal order, but only up and down is free to use.

And by the way, CJK input method is still a problem here, since they need to "Compose" before search. If you guys want to replace this function with the CTRL+I one. CTRL+I have no problem with input method, while the normal one cannot be used with input method. But for nautilus, the case will be different, people cannot use keys similar ctrl + i to trigger the input field, so they must type a useless key to trigger search, and then enable input method with hotkey, for example ctrl space.

What in my mind is like this: merge two search, both direct key, and the ctrl + I one. put a visible current search string somewhere, don't make cursor movable, use qlabel or something similar to display. Normal character key can trigger it, or ctrl + I can also trigger it. Make sure it accept input method event, otherwise it will be a drawback for CJK user. For input method, there is a similar case in mangonel, and I already propose a patch to make input method preedit works right: http://paste.ubuntu.com/666967/. I think it can also applied to this case. Left Right, Up and down can be used to move to next match item on different direction.

Concerning the arrow keys, you have a point, that might really be a disadvantage of the Nautilus approach, and showing the search string in a simple label rather than in a line edit might make sense.

I think merging the two search mechanisms is not an option because the way they work is too different (only match the beginning of file names/match any part of the file name). If we only use the filter bar approach, we lose the possibility to find an item by entering its first letter, and if we only use the other keyboard search mechanism, we cannot easily fiter, e.g., jpg files by entering 'jpg' in the filter bar any more.

Concerning the input method issue: if I understand you correctly, using the filter bar (triggered by Ctrl+I) works fine for you in connection with the input method? Or can we do anything to improve using that for input method users?

sorry, I forget filter bar is different.. (prefix and whole name) yes so they should not be merged.

For input method users, compose usually requires several keys for one single character or a string, and might take a quite long time. For Qt, if a widget don't accept input method event, it will not work with input method, in spite of widgets like text field which already handle things correctly themselves. Ctrl+I filter bar works simply because it use a text field, and no extra code is needed.

And due to compose with input method is more difficult (.. naturally), input method user prefer use English character in file name other than their own language. And for input method user, if there is no visual hint, for example: a text field, they will not know they CAN use input method here. There must popup something empty and indicate "people can input here". So not support input method for prefix search at all is Ok for most people.

And I think Ctrl + I is Ok for most input method user, in spite the key navigation... is there a way to easily move focus back to icon view with keyboard and keep filter bar open?

Git commit d8732a59d3b1f2d0bebf43f294df7e9f333abde4 by Frank Reininghaus.
Committed on 05/04/2012 at 18:59.
Pushed by freininghaus into branch 'KDE/4.8'.

Reduce the timeout in KItemListKeyboardSearchManager to 1 second

It turned out that the longer timeout, introduced recently in
02eab49b2de51c31fe46a0d9501327b579b3648e, not only made multi-letter
keyboard searches easier, but also had some unwanted side effects. I
hope that 1 second, which is between the previous value of 5 seconds and
the pre-KDE 4.8.2 value of 0.4 seconds, is a compromise which will fit
most users' needs.
We will try to improve the situation further in future releases by
providing visual feedback about the keyboard search, but such a change
would not be suitable for a bug-fix release.
Related: bug 297488

M  +1    -1    dolphin/src/kitemviews/kitemlistkeyboardsearchmanager.cpp

http://commits.kde.org/kde-baseapps/d8732a59d3b1f2d0bebf43f294df7e9f333abde4

I think this is better suited here than opening a new bug...

I just noticed this problem as well, but it's affecting me slightly different: the search 'history' is not cleared when entering a new directory.  So, if I'm in my home directory and type 'doc<enter>', that will put me in my documents folder.  Now, if I type 'pic<enter>' to select and enter my pictures folder... nothing happens.  Well, that's not true: I enter whatever folder happens to be listed first in my documents folder.

It appears that the previous search history is not cleared when entering the new folder, so the pic doesn't match anything.  <enter>, however, still fires off, so it'll activate whatever file is currently selected, even if it's not the correct file.  The only way I can get down to my pictiures folder is to count (slowly) to 5 and try again, switch to cursor navigation, or (heaven forbid) take my hands off the keyboard and use a mouse.

Dropping this down to 1 second will help alliviate the symptoms, but not solve this problem.  If a new folder is entered, the search history should be reset so that when I start typing a new filename pattern it should immediately start searching that new directory.

(In reply to comment #13)
> Dropping this down to 1 second will help alliviate the symptoms, but not solve this problem.  If a new folder is entered, the search history should be reset so that when I start typing a new filename pattern it should immediately start searching that new directory.

See this bug report and the patch I attached: https://bugs.kde.org/show_bug.cgi?id=297488#c7

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

(In reply to comment #14)
> See this bug report and the patch I attached:
> https://bugs.kde.org/show_bug.cgi?id=297488#c7

Thanks, Leszek.  Missed that one in my search.  Glad it's already being addressed.  :-)

(In reply to comment #11)

Thanks for the detailed explanation!

Git commit d3b1312d3edc615b03fb17c1a5fa62ccb61cdabd by Frank Reininghaus.
Committed on 25/04/2012 at 08:51.
Pushed by freininghaus into branch 'KDE/4.8'.

When Esc is pressed, clear the selection and cancel the keyboard search

This patch restores the Dolphin 1.x behaviour that Esc clears the
selection (Dolphin 2.0 did not have an easy way to clear the selection
using the keyboard so far). Moreover, Esc now also cancels the current
keyboard search. This fixes the problem that the only way to cancel the
search is to wait until the timeout has expired.
Related: bug 298742
FIXED-IN: 4.8.3

M  +7    -0    dolphin/src/kitemviews/kitemlistcontroller.cpp
M  +4    -2    dolphin/src/kitemviews/kitemlistkeyboardsearchmanager.cpp
M  +2    -0    dolphin/src/kitemviews/kitemlistkeyboardsearchmanager_p.h

http://commits.kde.org/kde-baseapps/d3b1312d3edc615b03fb17c1a5fa62ccb61cdabd

Git commit dc6667b72a5d7a987e61e4d85b8ddfb64f461489 by Frank Reininghaus.
Committed on 25/04/2012 at 09:17.
Pushed by freininghaus into branch 'master'.

When Esc is pressed, clear the selection and cancel the keyboard search

This patch restores the Dolphin 1.x behaviour that Esc clears the
selection (Dolphin 2.0 did not have an easy way to clear the selection
using the keyboard so far). Moreover, Esc now also cancels the current
keyboard search. This fixes the problem that the only way to cancel the
search is to wait until the timeout has expired.
Related: bug 298742
(cherry picked from commit d3b1312d3edc615b03fb17c1a5fa62ccb61cdabd)

M  +7    -0    dolphin/src/kitemviews/kitemlistcontroller.cpp
M  +4    -2    dolphin/src/kitemviews/private/kitemlistkeyboardsearchmanager.cpp
M  +2    -0    dolphin/src/kitemviews/private/kitemlistkeyboardsearchmanager.h

http://commits.kde.org/kde-baseapps/dc6667b72a5d7a987e61e4d85b8ddfb64f461489

There seems to be another issue unmasked by the 5 seconds delay (which has already been lowered again to 1 s AFAICS): When performing a keyboard search to select a folder, the search buffer is not immediately cleared upon hitting the "return" key and entering the folder. Instead, one has to wait for the timeout to elapse to be able to start a new keyboard search. This especially prevents an efficient workflow when traversing some recursively nested directories solely via keyboard navigation.

(In reply to comment #20)
> There seems to be another issue unmasked by the 5 seconds delay 

Already fixed with this also: https://bugs.kde.org/show_bug.cgi?id=297488#c7

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

I've another sugession with this.

The use case: user wants to search a list of entries by name, using minimal effort.

As discussed, and agreed with, a search label should be used, but without cursor navigation.

1) I suggest wildcards too -- when we use *, ? etc... all matching entries should be selected. Also it's unlikely a user will use names with these charectors.

2) When a user starts typing, the label should show sugessions (in the form of a list) of all the matches with that search string.
The user can then navigate the list using tab or back tab. Whatever he selects from the list, will get selected.

3) The text label follows the current match -- if entry 'abc' is matched, the search label (in icon view atleast) will be shown under 'abc'. This'll avoid the user having to look at 2 different places for the task.

I confirm the commnits work.

This bug should be resolved fixed.

Resetting assignee to default as per bug #305719

For what it's worth, even with the delay decreased to 1 second, I still find it annoying. I'm a relatively fast typist; before I could quickly select different files using the keyboard, but now I actually have to pause and wait for the previous query to be cleared (didn't know about Escape before, that's something I'll use more often).

Here's an example of what I mean:

Task: Open a file that may be called "dolphin_screenshot.png" or "screenshot_dolphin.png".

Before: type "do", no matching files seems to have been found, type "scr" instead.

Now: type "do", no matching file found. Type "s", doesn't work, wait 1 second and type "scr".

Obviously the preferred delay depends on how fast a typist you are. Therefore I think the best option would be to use QApplication::keyboardInputInterval() (or something similar) like before, and provide an option to configure the delay it in System Settings. This should affect other GUI elements as well, such as combo boxes and lists.

(In reply to comment #26)
> Therefore I think the best option would be to use
> QApplication::keyboardInputInterval() (or something similar) like before,

The problem is that QApplication::keyboardInputInterval() is actually supposed to mean something completely different, namely, the time after which a long key press is interpreted as multiple key presses. I think that there is no reason to assume that the value which is good for that delay is also the right value for the keyboard search timeout. I really don't understand why QAbstractItemview's keyboard search apparently does assume that - I guess the engineer who wrote the code just thought that "keyboardInputInterval" sounds like it's doing the right thing and did not look up what the setting actually means.

Adding a second setting for the "keyboard search timeout" might make sense if it was used everywhere in KDE, but the problem is that everything that uses Qt's itemviews (including combo boxes and most lists) uses the keyboard search code from QAbstractItemView which uses QApplication::keyboardInputInterval().

Unless we find a way to add a "keyboard search timeout" setting that is respected everywhere in KDE, I think that we should probably not make any further changes for the time being. Before the timeout was extended, we regularly got reports that it is far too difficult to search with multiple letters (in fact, many users didn't even know that they can type multiple letters because the timeout was so short). I see that the change is less helpful for users like you who type fast, but I believe that there are more users who benefit from the change, and considering that the search can also be aborted by pressing Esc, I consider the issue raised in the original report fixed and say that we should close this report.

Thanks to everyone who provided feedback concerning keyboard search!

(In reply to comment #27)
> The problem is that QApplication::keyboardInputInterval() is actually
> supposed to mean something completely different, namely, the time after
> which a long key press is interpreted as multiple key presses. I think that
> there is no reason to assume that the value which is good for that delay is
> also the right value for the keyboard search timeout. I really don't
> understand why QAbstractItemview's keyboard search apparently does assume
> that - I guess the engineer who wrote the code just thought that
> "keyboardInputInterval" sounds like it's doing the right thing and did not
> look up what the setting actually means.

Aha, didn't know that. Well for me the default value is about perfect.

> Adding a second setting for the "keyboard search timeout" might make sense
> if it was used everywhere in KDE, but the problem is that everything that
> uses Qt's itemviews (including combo boxes and most lists) uses the keyboard
> search code from QAbstractItemView which uses
> QApplication::keyboardInputInterval().
> 
> Unless we find a way to add a "keyboard search timeout" setting that is
> respected everywhere in KDE, I think that we should probably not make any
> further changes for the time being. Before the timeout was extended, we
> regularly got reports that it is far too difficult to search with multiple
> letters (in fact, many users didn't even know that they can type multiple
> letters because the timeout was so short). I see that the change is less
> helpful for users like you who type fast, but I believe that there are more
> users who benefit from the change, and considering that the search can also
> be aborted by pressing Esc, I consider the issue raised in the original
> report fixed and say that we should close this report.

Yes, I agree that the change is helpful for some users and that the timeout shouldn't be changed back and forth. Personally I would be happy with a hidden option to set the delay (e.g. in dolphinrc), but from what I understand you don't like that (reference: a forum post that I can't find at the moment), and that's perfectly understandable. So here's another idea:

Introduce a "Filter when typing text" option. When enabled, typing text will open the filter bar and put that text in the filter textbox. To make it work better, two changes are needed for how filtering works:
1. It should automatically select the first match.
2. When pressing Enter, open the file or folder. If it's a folder, reset the filter textbox and hide the filter bar.

This would work as a nice alternative for people who type slower and/or want to see what they type, while keeping the old way of navigating quickly with the keyboard for people who prefer that. If filtering seems too different from the current behavior, just selecting with a textbox (like e.g. Nautilus) is fine as well - as long as it's an option, or I'll have to patch Dolphin in the future... ;)

(In reply to comment #28)
> Yes, I agree that the change is helpful for some users and that the timeout
> shouldn't be changed back and forth. Personally I would be happy with a
> hidden option to set the delay (e.g. in dolphinrc), but from what I
> understand you don't like that (reference: a forum post that I can't find at
> the moment), and that's perfectly understandable.

This sounds a bit like hidden options are a common way of resolving issues like this, and I am the odd person who just doesn't like them ;-)

I see it like this: if there is agreement that something should be configurable, add a visible option, if not, then don't. There are only very few exceptional cases where hidden options might make sense (even though I would consider them more as a hack than as a solution for a problem), and this might indeed be one of them because:

a) Considering that stuff like the already mentioned 'keyboardInputInterval' and other properties of QApplication like 'startDragDistance' etc. can be configured in the system settings, there is no reason why the keyboard search timeout should not be configurable.

b) It cannot be added as a visible option to the system settings because Dolphin would be the only application that respects it. And adding an option for this in Dolphin's settings while the other properties can be set in the system settings is a bad solution too.

However, adding such a hidden option would require quite a few code changes unless we introduce a dependency on the settings class in KItemListController (which is something that I really don't want because all code in the src/kitemviews/ directory is currently completely independent from the rest of Dolphin): We would have to add a function to change the value in KItemListController, KItemListView, DolphinView, and (because the setting should of course also be respected in the Folders Panel for consistency) FoldersPanel.

From my point of view, the best solution would be to add a new property keyboardSearchTimeout to QApplication and make both QAbstractItemView and Dolphin respect it, but I'm not sure if the Qt people would like that idea. From what I get, there is not much work going into Qt's itemviews, and I don't know at all if and how keyboard search is handled in QML.

> So here's another idea:
> 
> Introduce a "Filter when typing text" option. When enabled, typing text will
> open the filter bar and put that text in the filter textbox. To make it work
> better, two changes are needed for how filtering works:
> 1. It should automatically select the first match.
> 2. When pressing Enter, open the file or folder. If it's a folder, reset the
> filter textbox and hide the filter bar.
> 
> This would work as a nice alternative for people who type slower and/or want
> to see what they type, while keeping the old way of navigating quickly with
> the keyboard for people who prefer that. If filtering seems too different
> from the current behavior, just selecting with a textbox (like e.g.
> Nautilus) is fine as well - as long as it's an option, or I'll have to patch
> Dolphin in the future... ;)

I think that filtering and searching are rather different things that should better not be mixed. There are some use cases where filtering is used in connection with selecting, and we would probably cause quite a bit of trouble if we made filtering always select the first match.

(In reply to comment #29)
> This sounds a bit like hidden options are a common way of resolving issues
> like this, and I am the odd person who just doesn't like them ;-)

Nah, I think it's just an easy workaround for users (they get what they want while there is no noticeable change for other users). However, I can see why developers don't like hidden options.

> a) Considering that stuff like the already mentioned 'keyboardInputInterval'
> and other properties of QApplication like 'startDragDistance' etc. can be
> configured in the system settings, there is no reason why the keyboard
> search timeout should not be configurable.
> 
> b) It cannot be added as a visible option to the system settings because
> Dolphin would be the only application that respects it. And adding an option
> for this in Dolphin's settings while the other properties can be set in the
> system settings is a bad solution too.
> 
> However, adding such a hidden option would require quite a few code changes
> unless we introduce a dependency on the settings class in
> KItemListController (which is something that I really don't want because all
> code in the src/kitemviews/ directory is currently completely independent
> from the rest of Dolphin): We would have to add a function to change the
> value in KItemListController, KItemListView, DolphinView, and (because the
> setting should of course also be respected in the Folders Panel for
> consistency) FoldersPanel.
> 
> From my point of view, the best solution would be to add a new property
> keyboardSearchTimeout to QApplication and make both QAbstractItemView and
> Dolphin respect it, but I'm not sure if the Qt people would like that idea.
> From what I get, there is not much work going into Qt's itemviews, and I
> don't know at all if and how keyboard search is handled in QML.

I agree with that, but I forgot to mention that I think it's very unlikely that it's going to happen anytime soon - as I understand, a lot of QWidgets would need to be change to respect this new property. That's why I suggested an alternative way.

But who knows? Maybe I should try to file a bug against Qt.

(In reply to comment #30)
> I agree with that, but I forgot to mention that I think it's very unlikely
> that it's going to happen anytime soon - as I understand, a lot of QWidgets
> would need to be change to respect this new property.

What exactly needs to be changed from your point of view except

void QAbstractItemView::keyboardSearch(const QString &search) ?

(In reply to comment #31)
> What exactly needs to be changed from your point of view except
> 
> void QAbstractItemView::keyboardSearch(const QString &search) ?

I don't know the internals of Qt very well, I just assumed that pretty much every list QWidget (i.e., all widgets that use a timeout) would have to be updated. Maybe it's not as bad as I made it sound.