After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 344785 - Incorperate Beagle Search in GtkFileChooser
Incorperate Beagle Search in GtkFileChooser
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.8.x
Other Linux
: Normal enhancement
: ---
Assigned To: Federico Mena Quintero
Federico Mena Quintero
Depends on:
Blocks: 435342 435343
 
 
Reported: 2006-06-13 17:21 UTC by Kevin Kubasik
Modified: 2007-05-04 11:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
Fredrico's patch for beagle search in GtkFileChooser (82.09 KB, patch)
2006-06-13 17:23 UTC, Kevin Kubasik
none Details | Review
another attempt (131.56 KB, patch)
2006-11-17 19:14 UTC, Matthias Clasen
none Details | Review
gtk+-2.10.4-search.patch (136.13 KB, patch)
2006-12-14 01:56 UTC, Federico Mena Quintero
none Details | Review
patch updated to gtk+ trunk (83.71 KB, patch)
2007-03-13 06:38 UTC, Emmanuele Bassi (:ebassi)
accepted-commit_now Details | Review
Updated patch, applying to trunk (138.16 KB, patch)
2007-05-02 19:32 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Updated patch, v2 (139.54 KB, patch)
2007-05-02 20:00 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review

Description Kevin Kubasik 2006-06-13 17:21:45 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.
Comment 1 Kevin Kubasik 2006-06-13 17:23:12 UTC
Created attachment 67272 [details] [review]
Fredrico's patch for beagle search in GtkFileChooser

Here's the patch I mentioned.
Comment 2 Olav Vitters 2006-06-13 21:21:40 UTC
Kevin: Federico is a gtk+ developer.
Comment 3 Kevin Kubasik 2006-06-13 21:25:31 UTC
heheh... right....

yeah


So on a less dumber note ;) Are there any plans to implement something like this upstream?
Comment 4 Kevin Kubasik 2006-10-13 16:17:57 UTC
Any thoughts on this yet? Just making it a compile-time option if distrobutions want it?
Comment 5 Matthias Clasen 2006-11-17 19:14:11 UTC
Created attachment 76777 [details] [review]
another attempt
Comment 6 Matthias Clasen 2006-11-17 19:26:31 UTC
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
Comment 7 Emmanuele Bassi (:ebassi) 2006-11-17 19:48:08 UTC
[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. :-)
Comment 8 Kevin Kubasik 2006-11-19 06:21:44 UTC
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.
Comment 9 Kevin Kubasik 2006-11-19 06:24:09 UTC
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.
https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/49608
Comment 10 Kevin Kubasik 2006-12-13 09:01:36 UTC
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?
Comment 11 Matthias Clasen 2006-12-13 16:42:33 UTC
We are considering it, as this bug shows...
Comment 12 Federico Mena Quintero 2006-12-14 01:56:58 UTC
Created attachment 78337 [details] [review]
gtk+-2.10.4-search.patch

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!
Comment 13 Matthias Clasen 2006-12-15 19:08:41 UTC
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.
Comment 14 Federico Mena Quintero 2007-01-02 19:00:17 UTC
(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).
Comment 15 Mikkel Kamstrup Erlandsen 2007-01-15 12:31:14 UTC
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:

http://wiki.freedesktop.org/wiki/WasabiSearchSimple
http://wiki.freedesktop.org/wiki/WasabiSearchLive
http://wiki.freedesktop.org/wiki/WasabiQueryLanguage

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.

Cheers
Comment 16 Federico Mena Quintero 2007-01-25 20:35:54 UTC
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.
Comment 17 Emmanuele Bassi (:ebassi) 2007-03-13 06:38:25 UTC
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.
Comment 18 Federico Mena Quintero 2007-03-15 01:16:36 UTC
Thanks for updating this, Emmanuele :)
Comment 19 Matthias Clasen 2007-04-28 23:52:22 UTC
Federico, do you intend to work on the issues outlined in comment 16 ?
Comment 20 Federico Mena Quintero 2007-04-30 16:00:37 UTC
Not for now, but at some point when time allows...
Comment 21 Matthias Clasen 2007-04-30 16:06:20 UTC
Do you think we should get the patch in trunk as-is, and file separate bugs for 
improving the search support ?
Comment 22 Federico Mena Quintero 2007-04-30 19:38:51 UTC
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?
Comment 23 Matthias Clasen 2007-05-02 18:50:22 UTC
Emmanuele, do you want to commit your patch ?
Comment 24 Emmanuele Bassi (:ebassi) 2007-05-02 19:29:27 UTC
sure.

I've resync'ed it with trunk, will attach here for reference.
Comment 25 Emmanuele Bassi (:ebassi) 2007-05-02 19:32:05 UTC
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.
Comment 26 Emmanuele Bassi (:ebassi) 2007-05-02 20:00:55 UTC
Created attachment 87407 [details] [review]
Updated patch, v2

another attempt, fixing a compilation error. also, added a ChangeLog.
Comment 27 Emmanuele Bassi (:ebassi) 2007-05-02 22:50:31 UTC
committed to trunk, I've filed bug #435343 for the issues Federico pointed out in comment #16

2007-05-02  Emmanuele Bassi  <ebassi@gnome.org>

	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
	object.

	* 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
	engines.

	* gtk/gtkfilechooserprivate.h:
	* 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"
	virtual shortcut.

	* gtk/Makefile.am: Update the build with the new files

Comment 28 Richard Hult 2007-05-03 20:37:46 UTC
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?
Comment 29 Emmanuele Bassi (:ebassi) 2007-05-04 09:56:15 UTC
(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.
Comment 30 Richard Hult 2007-05-04 11:38:00 UTC
Done, bug #435797. I hadn't seen the ftw proposal before, nice!