Search support for the GtkFileChooser (#344785) landed in GTK+ trunk. It’s a patch written by Federico and updated by Matthias Clasen (I merely kept it in sync with trunk). The patch adds a private search engine abstraction object and three implementations, using libbeagle, libtracker and a simple file-tree-walking search. There’s no hard dependency on Beagle or Tracker: the libraries are opened using g_module_open() if they are found installed on your system, otherwise it’ll all fall back to the simple search backend (it’s the same solution used by Nautilus for its search support).
The file chooser now has a “Search” shortcut:
If you double click it, you’ll get a search pane:
Where you can search for “foo” and get the matching results:
Next stop: fix all the missing bits (#435343) and add a “Recently Used” shortcut showing the list of recently used files (bug #435342).
By the way: libbeagle has an incredibly nice API, whereas libtracker doesn’t. Please, Tracker developers: instead patching projects or writing a GTK+ widgets library which only new projects can use, focus on writing a nice, GObject-based API for all the existing projects out there. Pretty please, with the sugar on top.
This really is a nice piece of work. I’m looking forward to use this much desired functionnality. However, regarding the usability of GtkFileChooser,
what about :
http://bugzilla.gnome.org/show_bug.cgi?id=357956 ?
This does not seem to have changed and I cannot find any relevent discussion on the mailing lists.
Thanks for the good work anyway.
Which theme is this ?
The expectation will now be for a search item in the nautilus sidebar as well. It would be nice if these two interfaces were designed together so that users are not confused or mix them up.
Search isn’t a place…. now I’ve nitpicked .. very nice work!!
Good work. So far, I have one thinking that is the abstraction search engines should be implemented on a lower layer, so Nautilus, deskbar and others could use them. I know it isn’t finished yet but gvfs seems a good place.
About the Tracker API: Why didn’t you use the D-Bus API provided by tracker?
Would have seemed as a much cleaner solution for me.
Ignacius: You are talking about xesam. See http://wiki.freedesktop.org/wiki/XesamAbout.
This should also cover the Tracker API-niceness request. Withing a relatively short time we should all just be able to use libxesam-glib or whatever it will be called, and have pervasive desktop search without much hassle.
Hehe, spot the WordPress bug in my comment above and receive 1 years worth of free air.
search is nice, but do we have a nice “recent files” display that works across all applications?
Good stuff! I’ve been hoping this would happen one day since 2004 :)
I wonder if “places” is the right UI for search though. Not where I’d expect to find it. What about a search button to the right of the location bar? It’s not overloading the widget because typing in the location is also a form of search.
*puts on asbestos underwear*
So, what does the button do? :)
Thanks for this Emmanuel, it will be very useful, I’m sure.
But where is the “Search” button in the first screenshot? Or am I getting the wrong end of the stick? Is it a keyboard shortcut? If so, how does the user discover it?
Mikkel: are you referring to WordPress not being smart enough to induce that the period is not part of your URL?
That’s what you get for ignoring .
OK, the real bug is that WordPress doesn’t allow http://www.ietf.org/rfc/rfc2396.txt :-)
ken: Spot on about the trailing period :-)
some replies without any order:
@John Williams:
there’s a big “Search” shortcut at the top of the shortcuts list.
@Michael:
because this is gtk+, and gtk+ doesn’t (yet) depend on d-bus; also why on earth should I use directly d-bus and go through the pain of using the C bindings, while someone else should do this work for me (as a developer)? beagle developers did make my life easier.
@ulrik sverdrup:
nautilus uses a different UI for searching, which is not reusable in the file chooser.
@Benoît:
it’s darkilouche, by jimmac.
@Mikkel:
I’d really like to have a libxesam-glib to use in my applications. is there a timeframe for a reference implementation?
IM IN UR SEARCH EATED RECENT FILES!!!!
@mhr
I thought I bore the hell out of everyone already, but it seems I was wrong. ;-) anyway, since gtk+ 2.10 we have an API for that – GtkRecentManager.
@fan
O RLY?
ebassi: Well, we are still finishing off the metadata part of the spec, but I have started to work on a python-glib binding to get a feeling on how the API should look.
The current hard deadline for the spec is 1st of June and I anticipate that libxesam-{glib,qt} will start evolving alongside the discussions and be ready for consumption maybe as early as july.
Many people have shown interest and said that they would help with the coding, so with a bit of luck we might be up pretty quickly.
The main blocker atm is that our FDO project request seems to be frozen in time… :-( We might have to move to Track or some other neutral host if something doesn’t happen soonish.
Great work! I can see this feature being very useful.
There’s one thing I am still missing from the GTK file chooser, and that is thumbnail view. Sometimes I need to browse for an image file, but the application I am using does not have a preview for the selected file (like Gimp has in it’s file chooser). It would be really handy to be able to switch between list and thumbnail/icon view. Just like in Nautilus and (ahem) Windows file choosers.
Another thing I think would be handy is the ability to create folders inside any GTK file chooser.