GTK Open Files – Search

A while ago I saw a proposal to add search to the GTK FileChooser dialogs by adding a Search item to Places and thought there has to be better way. Perhaps even better than adding a separate search entry. So here’s my attempt at combining path-bar, location entry, search and making type-ahead find with its problematic pop-up unnecessary. Based on Gedit’s dialog as example.

Click on the thumbnails for full size images.

GTK Open Files Search

The path elements are click-able for navigation, but appear as contents of the entry to give more sense to navigating upwards via backspace. They contain / to give a hint to its use for entering a folder (typing foo/ to enter foo). The entry also accepts ../ to go up, / as start of an absolute path and ~ for home.

Text entered is used for a recursive search on file/folder names in the current folder. Followed by a search inside files, a system-wide search and maybe a system-wide search inside files. Where system-wide could be limited to what a user is allowed to access. There would also be a search for tags wherever available.

The entry has a split for Name and Modified lined up with columns below. So the second part allows searches based on date of modification. There could of course be a third column and entry-segment fo size.

Finally something I had to at least try once. For all I know, current layout mechanisms don’t cover such things and I’m in doubt if it would be worth it:
GTK Open Files Search B


About thorwil
I'm a designer from Germany. My main interests are visual and interaction design, free/open-source software and (electronic) music.

6 Responses to GTK Open Files – Search

  1. Calum says:

    Hmm, looks quite powerful, but quite complex too. I’d be quite happy with something simpler, like OSX:

    – Add a “search” toggle button beside the current “location” toggle button
    – When search button is selected, show a text field, like the location text field
    – User types search terms in text field; all matching filenames below the current level are shown in the list on the right.
    – Click the search button again to hide the text field/search results.

    You’d probably want to arrange it so that search and location fields couldn’t both be shown at the same time, would keep things simpler and neater.

  2. thorwil says:

    Adding modality doesn’t make things simpler. The look could surely be improved, though.

    I see it as an advantage of my proposal that there are no toggle buttons. The user immediately gets to see all there is and has not to guess or try what hides behind some button.

    Also one has not to pay attention what the mode is, as it’s always the same. I know the location entry got in my way a few times when I didn’t expect it to be on.

    Thanks for the comment.

  3. Calum says:

    Well, one concern I’d have with your approach would be how quickly the results list could populate itself as you typed. Most of the time I’m not interested in the search results because I know where I’m going, so unless the results update was so instantaneous as to not delay the appearance of each letter I typed, I would find it annoying. Having a separate search ‘mode’ might turn out to be necessary for that reason alone.

    Being a minimalistic sort of guy, I guess I also prefer the simplicity of the results list in OSX– it doesn’t have explicit headers in the results area, it just shows you a list of filenames. For me, that’s enough to pick the file I was looking for first time, although I certainly understand why you’ve included the headers in your mockup. And also that I’m not really a typical user any more than anyone reading this blog probably is 🙂

  4. thorwil says:

    Before something is typed, you’d see a file list like now. It would not go away until the first hit is found. With incremental search, results for the current folder should be practically instantaneous.

    Searching all the way down and system-wide takes time of course. The results should appear as they come in and some spinning symbol as the last item could indicate the search is still in progress.

    The results do belong to different categories and the user should not be left wondering why something is in the results. There could be files with the same name, but from different folders. What would you do in the last case, with OSX?

  5. Sven says:

    You are aware that the Search item in the bookmarks list is not only proposed but already landed in GTK+ trunk? See Emmanuele’s blog

  6. thorwil says:

    Sven: well, now I am aware. That search is a place. Thanks.