GNOME Bugzilla – Bug 344785
Incorperate Beagle Search in GtkFileChooser
Last modified: 2007-05-04 11:38:00 UTC
There is a patch by Federico Mena Quintero that applies cleanly to most of the 2.8 series. If people doubt the usefulness of an all encompassing and integrated search in a file chooser, I can go on a rant to explain myself, but I at least wanted to get a bug in about the idea.
Created attachment 67272 [details] [review]
Fredrico's patch for beagle search in GtkFileChooser
Here's the patch I mentioned.
Kevin: Federico is a gtk+ developer.
So on a less dumber note ;) Are there any plans to implement something like this upstream?
Any thoughts on this yet? Just making it a compile-time option if distrobutions want it?
Created attachment 76777 [details] [review]
Here is another attempt, which ports the NautilusSearchEngine framework
from nautilus. The patch I attached still has the dlopen hacks that we
use in Fedora, but for upstreaming, we should probably just include
the required headers and add --enable-beagle/--enable-tracker to configure
[I'll put aside any snide remarks about the tracker backend]
part of this patch should be used to add recent files support to the file chooser - or, at least, it was my plan to use it ;-) - as a special location, like the "search" one.
so, at least the chunk adding the ability to programmatically create locations inside the file chooser should be required for the recent files integration.
I'll play with this patch and see what I can make up with it. :-)
Any chance of a target release guess? As far as incorporation into Ubuntu Feisty, I'm wondering if we might see this is a new gtk release soon, or if we should consider packaging the patch.
Since we have more than one Gtk dev looking at this, I'm marking it as NEW for the sake of general bugzilla order, but feel free to change/correct if you feel different. Or I'm just plain wrong.
And by the way, heres the bug in launchpad.
The patch looks pretty good, has anyone finalized/packaged it? If so, would we consider incorperating this upstream so we might start to see it in a few more distros?
We are considering it, as this bug shows...
Created attachment 78337 [details] [review]
The patch as posted didn't work. It is simply missing a call to _gtk_search_engine_set_query() right before telling the engine to start searching. With this change, it seems to work fine.
Matthias, thanks a lot for updating this!
Federico, one thing that has been proposed as a further improvement on the current patch: take the filter combo into account and filter search results.
I haven't looked at it, so I don't know how hard that would be to add, but it would certainly make sense.
(In reply to comment #13)
> Federico, one thing that has been proposed as a further improvement on the
> current patch: take the filter combo into account and filter search results.
> I haven't looked at it, so I don't know how hard that would be to add, but it
> would certainly make sense.
Yeah, it shouldn't be hard to add. I'll try to look into it soon (I need this for openSUSE as well).
I would like to give a pointer to the Wasabi project going on at xdg on fdo.
It is a project to create a unified dbus api for desktop indexers (and other related stuff when we come to that), but an api for desktop search is the top priority right now.
We are currently in the drafting phase, and don't have any proposals ready for public feedback. You can however get a sneak peak at:
All major desktop search providers I've been able to dig up have replied with interest. These include Beagle, Tracker, Strigi, Pinot, Recoll, and Nepomuk (of the top of my head - sorry if I forgot someone).
I'll return when we have public proposals.
Some issues with the patch:
Filter dropdown does not affect Search mode (in gedit you care only about text files,not about searchterm.jpg).
Paths and filenames in the same row look horrible.
No differentiation between files and folders; icons are not displayed. Double-clicking on a folder tries to open it as a filename.
Can't add bookmarks for items in a search result.
If I search and then go back to a place (like my home directory, or my desktop), double-clicking on Search takes me back to a blank slate. It would be nice if it remembered my last query.
No shortcut for Search.
Search not shown in Firefox.
Created attachment 84481 [details] [review]
patch updated to gtk+ trunk
I've updated the patch to apply to trunk; it seems to work properly with libbeagle installed.
Thanks for updating this, Emmanuele :)
Federico, do you intend to work on the issues outlined in comment 16 ?
Not for now, but at some point when time allows...
Do you think we should get the patch in trunk as-is, and file separate bugs for
improving the search support ?
Yeah, it's good enough to go into trunk, and it would let other people hack on it there. I don't have time to pull an updated tree from svn right now - do you have time to do it?
Emmanuele, do you want to commit your patch ?
I've resync'ed it with trunk, will attach here for reference.
Created attachment 87405 [details] [review]
Updated patch, applying to trunk
this is the same patch as above, resync'ed with trunk and with all the files added, this time.
Created attachment 87407 [details] [review]
Updated patch, v2
another attempt, fixing a compilation error. also, added a ChangeLog.
committed to trunk, I've filed bug #435343 for the issues Federico pointed out in comment #16
2007-05-02 Emmanuele Bassi <email@example.com>
Add search file support in the GtkFileChooser. Original patch
by Federico Mena Quintero; patch updated by Matthias Clasen.
See bug #344785.
* gtk/gtksearchengine.[ch]: Private search engine abstraction
* gtk/gtksearchenginebeagle.[ch]: Private search engine
implementation using libbeagle (via g_module_open()).
* gtk/gtksearchenginesimple.[ch]: Private search engine
implementation using file tree walking.
* gtk/gtksearchenginetracker.[ch]: Private earch engine
implementation using libtracker (via g_module_open()).
* gtk/gtkquery.[ch]: Private query object for the search
* gtk/gtkfilechooserdefault.c: Use the GtkSearchEngine to
query a search engine backend using GtkQuery; create a new
operating mode, OPERATION_MODE_SEARCH, and call the common
operating mode OPERATION_MODE_BROWSE; add support for virtual
shortcuts inside the shortcuts model and create a new "Search"
* gtk/Makefile.am: Update the build with the new files
This doesn't build on darwin due to ftw differences (the return values FTW_STOP etc are glibc specific I think). Has anyone tried building this on the other BSDs?
(In reply to comment #28)
> This doesn't build on darwin due to ftw differences (the return values FTW_STOP
> etc are glibc specific I think).
Richard, could you open a bug about this so I can track the issue? I think now it's a good time to go on and implement the ftw()-like API in GLib as discussed in bug #157076.
Done, bug #435797. I hadn't seen the ftw proposal before, nice!