With the basic stuff in place, it’s now time to think about the way a search interface should be integrated into Thunar. Since Thunar is now (as was decided) fully navigational, the obvious solution of doing searches in a special window associated with a special (virtual) folder is not available.

Besides that, even this obvious solution has several issues, as can be seen with the latest proposals for nautilus-search2. One of the last comments on this blog entry summarizes many of the possible issues when treating a search view like a usual folder view:

We could say that searches, similarly to the CD burner, are not real “locations”, as far as Nautilus is concerned. This seems to give rise to certain problems, as the functionalities related to these objects differ from those of normal locations in Nautilus.

• You cannot paste a file into a search, or rather what logic would this serve ? Usually, when you cannot paste or move a file in nautilus, it is because the place is read only, or you do not have permission, not because it represents something other than a location.

• When you click on search in a browser window, you loose the utility of the cookie crumb navigator. (you get lost )

• When you click search in a spatial window, it actually opens the search in another window. Could this window not simply be a “search application window” rather than a Nautilus window ?

• Perhaps a list view would be the preferred default way to view a search results (irrelevant of the default nautilus setting), not only to view the path (and additional information for identifying files) but also to provide quick sorting (sorting is kind of like a second search).

• When you start a search with the tree view in the side pane, what should be shown as the current location in the tree view ?

• Subfolders in a saved search appear “inside” the saved search, however when you open a subfolder you get sent to the actual path of the folder. It would therefore seem that presenting search results like a folder could be the wrong metaphor.

• A user may want to add an emblem to a file in a saved search, but not to the actual file, or the other way around…

• When you change search parameters of a saved search, does it automatically save them, or ask for confirmation ? Both ways I can see this as problematic, as you generally do not save things in Nautilus.

• A saved search shows subfolders “inside” the search (in exactly the same way as files are “inside” folders), however when you click on these subfolders you are actually redirected to the real folder. Say I searched for files modified today ; as a user, considering a “virtual folder” type metaphor, I would assume to find only files modified today in the saved search subfolders.

• Seeing as files appear to be “inside” a saved search, could the user not think the files have been copied there ?

Actions applied to the contents of these special places differ substantially from those applied to other objects in nautilus, such as folders or network places, thus problems arise from trying to imitate normal Nautilus behavior. So many inconsistencies make me wonder if it is wise to integrate such functions as search or a CD burner into the file manager. The new search seems very impressive, but what are the real advantages of having this in Nautilus rather than separate ? To me it would seem much clearer if the CD burner was completely separate from the file manager, and if search was performed in a separate window.

The need for “not normal” folders, that gave rise to the “blue background” for me goes to show that this just should not be here. If the we must differentiate “special” nautilus browser windows, why not just put them in another window, or a separate application ? One consensus could be that a particular application window serves a particular purpose ; Nautilus is a navigator, not a burner or a search tool etc. You wouldn’t add a CD burner to evolution, even though it can save files, Nautilus would be adapted for browsing CVS or SVN though (as it is for FTP…).

Search as it is works without confusing anybody, although it lacks some much needed functionality. I think one of the main things currently missing (pre 2.13) is a button in nautilus that opens the search dialog ready to search in the current path, and saved searches ; plus of course backends, beagle… The main thing I am getting at here is that I do not think integrating search into Nautilus (represented similar to folders) is at all a step in the right direction, I think it will do more to confuse users than it does benefit them with the new functionality. I think the exact same functionality can be provided without integrating search into the file manager part of Nautilus, with an interface similar to the current implementation, added search buttons, a few modifications and addition of new capabilities.

I do hope I don’t seem too harsh, the new search is very impressive, and contains many very neat ideas, so much so that I feel rather bad about criticizing it. I was rather hesitant about posting this, as I don’t want to seem to be bashing other peoples hard work, but I am rather worried that we may be trading simplicity for snazziness here. It would seem to me that most people accept the new implementation as an improvement, but please give it a little thought.

I hope these comments will be found useful by some, hopefully for ideas to help make the GNOME interface both more simple and more functional.

arstechnica has a review of Spotlight in Mac OS X 10.4 Tiger. Spotlight is integrated well into most parts of the desktop, except the Finder.

• Screenshot of Spotlight in Navigational Window
• Screenshot of Spotlight in Spatial Window

As you can see from this two screenshots, the search ui itself is pretty well structured, but doesn’t really fit into the finder windows.

The best screenshot I could find of Windows Longhorn Desktop Search is this one. Here you can see (well, more or less) that there’s a dedicated user interface for the search view, with the most important widgets (search for entry widget, base folder selector and file type selector) visible above the search result view in a well-known manner.

Right now I tend to say that the best way to integrate a search view is a dedicated window, with only the widgets required for the search (I wouldn’t even include a menubar here). Pressing Ctrl+F (or “Search in this folder” from the context menu) in a thunar window would then open a new search window, with the viewed folder as (pre-selected) base folder for the search.

A python mockup should be created for the search window.

The search system should be integrated into Thunar-VFS, so it can be used by other applications as well (or even in a GtkFileSystem plugin based on Thunar-VFS). The system consists of a bunch of helper classes, an interface and one or more plugins that implement this interface. A local search implementation will be provided by Thunar-VFS and other plugins can provide integration with other services (like Beagle, KAT/Tenor, etc.).

The implementation shouldn’t take much time, compared to the UI integration.