Bug 324479 - Keyboard search doesn't handle spaces
Summary: Keyboard search doesn't handle spaces
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: view-engine: general (show other bugs)
Version: 4.11.0
Platform: Compiled Sources Linux
: NOR minor
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-03 23:38 UTC by Mark K Cowan
Modified: 2013-10-07 07:13 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.11.3


Attachments
Screengrab video showing four test-cases failing (1.31 MB, video/mp4)
2013-09-04 12:08 UTC, Mark K Cowan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark K Cowan 2013-09-03 23:38:27 UTC
When I open a file explorer, I usually navigate with the keyboard via autocomplete, "Doc<enter>My Pic<enter>" etc to go "./Documents/My Pictures".  This works without a hitch in Dolphin, except for when files have spaces in their names (e.g. the above "My Pictures" example, where I'm accessing my Windows pictures folder).

Rather than require spaces to be typed, it might be convenient to simply strip spaces in autocomplete, so for the above example, I'd use "Doc<enter>MyPic<enter>" rather than explicitly typing the space, since some minority of people probably have <space> configured to do something useful.

Reproducible: Always

Steps to Reproduce:
1. Open a folder which contains a file/folder which has a space in its name, and has a similar name to another file/folder  (e.g. a Windows "My Documents" folder containing "My Pictures", "My Videos", "My Music")
2. Try to navigate to one of those folders using autocomplete, i.e. no mouse or arrow keys
3. Where several items are identical up to their first <space> character, the first will be selected no matter what you type after the <space>.
Actual Results:  
See "steps to reproduce"

Expected Results:  
The autocomplete should be able to handle files with spaces in their names, possibly by the method in "details", last paragraph if <space> already has something binding in Dolphin.

Compiled from source, Arch Linux x64
Comment 1 Frank Reininghaus 2013-09-04 10:31:17 UTC
Thanks for the bug report. I can reproduce the problem, but only if some of the folders are created after the view has been loaded. In that case, the same problem occurs in the "Open file" dialog of other KDE applications, so this is most likely not a Dolphin bug.

(In reply to comment #0)
> Rather than require spaces to be typed, it might be convenient to simply
> strip spaces in autocomplete, so for the above example, I'd use
> "Doc<enter>MyPic<enter>" rather than explicitly typing the space, since some
> minority of people probably have <space> configured to do something useful.

In that case, it would be impossible to distinguish if the user wants to go to "MyPictures" or "My Pictures" (provided that two such folders exist).
Comment 2 Mark K Cowan 2013-09-04 12:08:44 UTC
Created attachment 82151 [details]
Screengrab video showing four test-cases failing

Notes:
The "Documents" folder is a symlink to a folder in /mnt/, which has an NTFS partition mounted on it via NTFS-3G (fuseblk).   I don't see how this matters to an autocomplete mechanism though.
Comment 3 Mark K Cowan 2013-09-04 12:09:50 UTC
> In that case, it would be impossible to distinguish if the user wants to go
> to "MyPictures" or "My Pictures" (provided that two such folders exist).

I know, however when was the last time anyone saw a situation like that, which wasn't due to a typo?
Comment 4 Frank Reininghaus 2013-09-04 12:23:51 UTC
(In reply to comment #3)
> > In that case, it would be impossible to distinguish if the user wants to go
> > to "MyPictures" or "My Pictures" (provided that two such folders exist).
> 
> I know, however when was the last time anyone saw a situation like that,
> which wasn't due to a typo?

It doesn't matter. If it is possible that a user has such folders, then it has to work for such folders. Otherwise, some users will notice that it doesn't work and file bug reports. It's as simple as that. 

Note that one can come up with lots of examples which are much less stupid then the one I gave above, maybe "The red paintings" and "Thermoelectric effect". If the user enters "Ther", then he will expect that only the latter folder is suggested by the autocompletion.
Comment 5 Mark K Cowan 2013-09-04 12:37:35 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > > In that case, it would be impossible to distinguish if the user wants to go
> > > to "MyPictures" or "My Pictures" (provided that two such folders exist).
> > 
> > I know, however when was the last time anyone saw a situation like that,
> > which wasn't due to a typo?
> 
> It doesn't matter. If it is possible that a user has such folders, then it
> has to work for such folders. Otherwise, some users will notice that it
> doesn't work and file bug reports. It's as simple as that. 
> 
> Note that one can come up with lots of examples which are much less stupid
> then the one I gave above, maybe "The red paintings" and "Thermoelectric
> effect". If the user enters "Ther", then he will expect that only the latter
> folder is suggested by the autocompletion.

Either way, just /some/ fix to the autocomplete bug would be nice.  I suggested the space-less method as there are probably more users who have <space> mapped to something than there are users with confusingly similar filenames.  Of course, with Linux being Linux, a simple tickbox in preferences could give a choice of both options without any compromise.

As for "The Red Paintings" and "thermoelectric", if the user is used to a space-less autocomplete then they would expect either name to match "ther", just as they are used to a case-insensitive autocomplete (hence why I changed the caps in your examples).  No-one files bug reports over "CAPS ON" and "caps off" both being matched by "CAP", "cap" and "Cap".
Comment 6 Christoph Feck 2013-09-04 23:05:15 UTC
> navigate with the keyboard via autocomplete

I fail to understand this bug report. Could you please describe in detail which widget has focus (and if it is the URL navigator, in which mode it is), and if it is about filename completion, in which mode you have set the completer popup?
Comment 7 Mark K Cowan 2013-09-05 01:34:10 UTC
(In reply to comment #6)
> > navigate with the keyboard via autocomplete
> 
> I fail to understand this bug report. Could you please describe in detail
> which widget has focus (and if it is the URL navigator, in which mode it
> is), and if it is about filename completion, in which mode you have set the
> completer popup?

I'd have thought that this was pretty clear from the video, the main view has focus.  Besides adding Dropbox extensions via preferences I don't think I've customised Dolphin at all.
Comment 8 Frank Reininghaus 2013-09-05 06:02:44 UTC
If the main view has focus, then I have misunderstood the original report (which did not contain the video) completely. Because it mentions changing folders and using autocompletion to navigate in a directory tree, I had thought that it must be related to the location bar.

Unfortunately, the computer which I'm sitting at currently refuses to play the video, and I can't do any testing at the moment.
Comment 9 Frank Reininghaus 2013-09-05 08:13:43 UTC
Still unable to open the video, but I think I see what you mean now. Sorry for the confusion - the term "autocomplete" confused me because the only place in the UI and the code where "completion" is used is the location bar, if I'm not mistaken. The feature you are referring to is called "keyboard search" internally.

Note that "Space" already does have a meaning: Ctrl+Space toggles the selection state of the current item, and Space (without modifiers) selects the current item if it is not selected yet. In principle, I think that there is no reason why the "Space" could not also be added to the current search string though.

Custom keyboard shortcuts are probably not a problem. I just assigned the shortcut "Space" to "Show the about dialog", and if I press Space then, the selection state is not changed. This means that for any users who use Space as a custom shortcut, Space will just not have any effect except for triggering the associated action.
Comment 10 Mark K Cowan 2013-09-05 11:22:11 UTC
The video plays on my £60 android phone, its a H.264 in MP4 container with no audio (VLC should handle that no problem).

Open dolphin, in the main view type the first few chars of a filename or folder name.  Notice that the file/folder is selected.  That's the completion that I'm talking about.  I don't mind whether the 'keyboard search' requires <space> for spaces or whether it skips them, just as long as it /can/ handle filenames with spaces somehow.
Comment 11 Frank Reininghaus 2013-10-07 07:13:50 UTC
Git commit c802f3d2e747c8874d1240e8e203b36384cae1cf by Frank Reininghaus.
Committed on 07/10/2013 at 07:08.
Pushed by freininghaus into branch 'KDE/4.11'.

Include "Space" in the keyboard search string

Before this commit, we only added pressed keys to the search string if
they have no other meaning. This means that files containing a Space in
their name could not be searched because Ctrl+Space toggles the
selection state of the current item, and Space alone selects the
current item.

After this commit, Space is added to the search string if

(a) the key press did not have any other effect, i.e., if Ctrl was not
    pressed, and the current item is selected already, and
(b) a keyboard search has been started already (to prevent unexpected
    effects when pressing Space accidentally - I think that it's rather
    uncommon to have files whose names start with a Space - and to make
    the unit test simpler).

I modified the unit test of KItemListController, which did not test
keyboard search yet. This uncovered a small problem in
KItemListController::slotChangeCurrentItem() when NoSelection mode is
used. It's not really relevant for anything that is executed inside
Dolphin, but I still fixed it to make the unit test happy.
FIXED-IN: 4.11.3
REVIEW: 113071

M  +26   -16   dolphin/src/kitemviews/kitemlistcontroller.cpp
M  +6    -0    dolphin/src/kitemviews/private/kitemlistkeyboardsearchmanager.cpp
M  +9    -2    dolphin/src/tests/kitemlistcontrollertest.cpp

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