Dolphin keyboard search improvement in KDE 4.8.2

If you read my previous post, you know that there is a Dolphin forum at forum.kde.org.
Thanks to a couple of very active forum members who are doing a really amazing job, many user questions are answered quite quickly. This is why I didn’t get involved in many topics so far: Every time I look at the forum, most new questions have been answered already, and the others are often about problems that I unfortunately can’t help with.

Today I’m going to tell you how the forum made me find and fix a bug in Dolphin. The other day, a new user asked some questions, one of which was about selecting a file by typing the first few letters of its name. Let me first give you some background information.

Let’s assume that we want to jump to a particular file in the current folder as quickly as possible. I will tell you about two ways to do this in Dolphin in a minute. As an example, I will consider the folder dolphin/src/views/ in Dolphin’s source code, which contains the files (I have “folders first” enabled, which is why tooltips and versioncontrol are first in the view):

tooltips
versioncontrol
additionalinfoaccessor.cpp
additionalinfoaccessor.h
dolphindirlister.cpp
dolphindirlister.h
many more dolphin* files…
draganddrophelper.cpp
draganddrophelper.h
renamedialog.cpp
renamedialog.h
viewmodecontroller.cpp
viewmodecontroller.h
viewproperties.cpp
viewproperties.h
zoomlevelinfo.cpp
zoomlevelinfo.h

Let’s assume that the file we are interested in is draganddrophelper.cpp.

Filter Bar

If you press Control+I, or select “Show Filter Bar” from the “Tools” menu, the filter bar is shown at the bottom of the view. Just enter any text there, and the view will only show files whose name contains this text. In our example, entering “dr” will hide all files except draganddrophelper.cpp and draganddrophelper.h

Keyboard Search

If you don’t want to use the filter bar, you can enter the first few letters of a file’s name to jump to this file. Pressing “d” will focus the first file whose name starts with the letter “d”, i.e., dolphindirlister.cpp. Now we expect that pressing “r” will take us to draganddrophelper.cpp. However, we will probably get to renamedialog.cpp instead – it seems that Dolphin forgot that we first entered a “d”! We will achieve the desired result only if we type very fast.

Digging into the code

In Dolphin 1.x, keyboard search was taken care of by QAbstractItemView. In Dolphin’s new view engine, the key event handling code is organized in a different way, but the behaviour is mostly the same. The idea is the following: All letters entered by the user are put together to a search string, and then the next file whose name starts with that string is focused. However, if a pause longer than some timeout value occurs between two key presses, it is assumed that the user wants to start a new search, and the previous search string is forgotten.

The problem is that this timeout is QApplication::keyboardInputInterval() in KDE <= 4.8.1 (and probably still today in QAbstractItemView). At first sight, the name of this function suggests that it does indeed have something to do with keyboard input, but the API docs tell us that it’s not quite what we need here, and that the default value is just 0.4 seconds. This is why we have to type so quickly to do a multi-letter keyboard search in Dolphin.

After a quick discussion on the kfm-devel list, we decided to increase the timeout to 5 seconds.

Some readers will probably note that Nautilus provides visual feedback about the search string during a keyboard search. If you read the mailing list thread, you will see that we would like to provide something similar in Dolphin as well. However, we can’t promise to implement this in the near future because our TODO-lists are quite long already :-(. A quick note to potential new contributors, just to prevent misunderstandings: Implementing such a feature requires thorough knowledge of Dolphin’s code base. People who would like to help out should therefore start with something easier first.

More bug fixes

Here is the complete list of Dolphin bug fixes in KDE 4.8.2, most of which were done by Peter, from the KDE 4.8.2 changelog:

  • Select files which have been pasted or dropped. Fixes bug 295389. See Git commit 210e5e3.
  • Prevent flickering of icons or previews when downloading files. See Git commit ef2ef83.
  • Fix sorting-issue when “Sort folders first” is disabled. Fixes bug 296437. See Git commit 7120e01.
  • Bypass crash in combination with the Polyester-style. Fixes bug 296453. See Git commit 010699e.
  • Fix alternate background issue in the Details mode. See Git commit f3e6298.
  • Fix translation-issue in the context-menu. Fixes bug 290620. See Git commit 44482f8.
  • Prevent endless scrolling when dragging items. Fixes bug 295584. See Git commit 6bf5f88.
  • Details view: Allow to turn off expandable folders like in Dolphin 1.7. Fixes bug 289090. See Git commit e04cb14.
  • Allow custom ordering of columns from the Details view. Fixes bug 164696. See Git commit b62c74e.
  • Increase the timeout for keyboard searches (typing the first few letters of a file name) to 5 seconds. See Git commit 02eab49.
About these ads

25 thoughts on “Dolphin keyboard search improvement in KDE 4.8.2

  1. elv13

    Why not enabling the filterbar by default (hidden, but active)? If:
    -Letters are pressed
    -No shortcuts are set to use single key (we can set custom shortcuts on ‘a’ alone, this would conflict)
    -A custom options enable “filter on keyboard press”

    Having 2 different system to focus file in redundant, any typing “very fast” is sometime hard for some peoples or when you have 1 hand on the mouse. So when users press keys in dolphin or open dialog it just show the filterbar and filter out content. Gnome does that and it seem to improve usability. Is there anything that prevent this from being the default?

    1. freininghaus Post author

      “So when users press keys in dolphin or open dialog it just show the filterbar and filter out content. Gnome does that”

      I think that this is not correct. When I enter letters in Nauilus 3.2.1, there is no filterbar. It’s a line edit that shows the keyboard search string.

  2. conrad

    The improved keyboad search is great, but the timeout is to long.
    It might be better to let the user decide, how the search should be handled. No hardcoded time for example and maybe and optical feedback, when the “typing time” is off.

      1. JanKusanagi

        After using it for a few days now, I also think the 5-second delay is too long.
        I guess something like 2 seconds would be better.

        But specifically I’d like to suggests 2 things:
        - Maybe this “pseudosearch” could be canceled by pressing Esc or something. This way, if you mess up what you were trying to locate, you can press Esc and start typing again.

        - Apparently the timeout does not reset after changing folders, so if I type “dow” to get to a Downloads folder, and then press enter, I can’t go to a “zsomething” file by typing “z”, until the 5 seconds are up. Maybe this is not supposed to happen, but that’s the behavior I get (Mageia 2 packages).

        Amazing work with all those bugfixed, by the way, much appreciated ;)

      2. JanKusanagi

        Oh, and maybe it could be nice if the “invisible search string” was reset if the user pressed the arrow keys, home/end or pgup/pgdown, which I guess usually means he/she has changed his/her mind, and wants to locate the file “manually” :D

  3. fasd

    Bug fixes :D I love this! I’m going to report feature request, because if I drag something onto icon on desktop (folder view mode) there is no feedback It’s the same case whether I drop on a folder or clean desktop. I think that highlight of folder should follow If I’m above with attempt to drop ;)

    1. freininghaus Post author

      Thanks, but I’m afraid that the comments section of a Dolphin developer’s blog is not quite the right place for filing Folder View feature requests ;-)

  4. Jens

    Hi,
    great to hear about that increased timeout.

    I really like the filter bar though as it also only shows items that match the entered search string. It has only one drawback – there is no fast way to get the keyboard focus back to the file view once you entered a filter. You may also want to have a look at this issue which I reported: https://bugs.kde.org/show_bug.cgi?id=297140

    Thanks a lot for you work, I really appreciate improvements in Dolphin, as it is one of my most used KDE applications (together with Konsole)

  5. Ryan James

    Maybe you should hold a poll in the forum as to that length of timeout. I personally like 2 seconds max but I am a very fast typer. That or make it an option that can be changed through a config file.

    1. freininghaus Post author

      Could you point out why you think that the longer timeout could be an annoyance for fast typers (if it’s not the problem about the continued search after changing the folder, see the comment below)?

  6. Leszek

    The downsize of the increased keyboard search delay is that you can’t navigate fast through your filesystem anymore this way.
    If you search for a folder and hit enter (and if you are really fast) the keyboard search pattern won’t delete right away whenentering a folder.
    So you need to wait the 5 seconds until you can navigate to the next folder.

    My current workaround for 4.8.2 is using the urlbar.

    Btw. I opened a bug report describing this buggy behavior here:https://bugs.kde.org/show_bug.cgi?id=297488

    1. freininghaus Post author

      You’re right, thanks for the bug report. This proves again that any kind of change, no matter how small it seems, can cause regressions :-(

      I’ll work on that for KDE 4.8.3.

      1. BajK

        Hm, at least the timer should be reset when entering a new directory, so you can immediately start typing. It seems that I always have to wait for the 5 seconds – well, now 1 second :) – to run out before it accepts my input again.

  7. BajK

    Just upgraded to 4.8.2 and now the auto-selecting while typing just doesn’t reliable work anymore :( When I enter a folder, I have to wait a few seconds before I can start typing, and after typing I also have to wait a massive amount of time before it actually does something then. I guess that input box thing that Gnome also does, is the best way to solve that.
    Also, it would be great if the breadcrumb bar also autocompleted file names, not just directory names. Often I want to directly open a certain file but it does not autocomplete them but either spits out an error if the file does not exist, or open it; but it does not “help” you in finding it.

    1. freininghaus Post author

      You’re right, I’m sorry about this inconvenience (see my other comment below).

      I’m not quite sure about the breadcrumb idea. I think it might be a bit confusing if not only possible folder completions, but also all matching files pop up while the user is entering a URL.

    1. Ashwin

      Sorry, it is working but i am actually addicted with previous keyboard search. So this improvements feels more like a bug than a feature

  8. freininghaus Post author

    @all: Thanks for your feedback! I’ve realised now that this change caused problems for some users because it made it obvious that

    1. There is currently no way to cancel a search manually:
    https://bugs.kde.org/show_bug.cgi?id=297458
    2. The current search is not cancelled when the URL has changed:
    https://bugs.kde.org/show_bug.cgi?id=297488

    For some users, the short timeout of 0.4 seconds was a nice workaround for these problems. For these users, 5 seconds are way too long :-(

    I hope that 1 seconds is a good compromise. I’ve changed the timeout to 1 second in the KDE/4.8 branch:

    https://projects.kde.org/projects/kde/kde-baseapps/repository/revisions/d8732a59d3b1f2d0bebf43f294df7e9f333abde4

    If you build Dolphin from source, just include this commit to get the 1 second timeout. I’ve notified the KDE packager mailing list about this issue as well. In any case, the 1 second timeout will be in KDE 4.8.3, and we’ll also work on the two problems I’ve mentioned above.

    I apologize for the inconvenience that I’ve caused. I see now that I should have done some more research about how the keyboard search is actually used by people before making such a change.

    1. JanKusanagi

      Ok, I realized now that I should’ve read all the comments before replying to one above :P

      1 second timeout sounds very reasonable, IMO :)

  9. Coupons Dealuxe

    Hi freininghaus. Is there any possibility of bringing back the resizable drag-to-select rectangle for Details view mode? This was standared for as long as I can remember before KDE 4.8. Now in KDE 4.8, the drag-to-select rectangle is always 100% of the folder, which isn’t so handy. The regular drag-to-select rectangle is present in Compact view mode, but Compact view mode doesn’t have expandable folders. It would be nice if the default behavior was returned or if the 100% width drag-to-select were made an option that could be toggled. This is a bit of a regression in terms of user-friendliness when attempting to select folders and files in Details view mode.

    1. freininghaus Post author

      Please file a feature request at bugs.kde.org about that and describe exactly why you think the new rubberband selection mode is less user-friendly.

  10. Pingback: KDEFamily - Dolphin i wyszukiwanie klawiaturowe

  11. Pingback: Keyboard search | Playstation3st

Comments are closed.