GNOME Bugzilla – Bug 319556
Add abilty to search by filename, comment, exif data, etc
Last modified: 2018-07-12 00:04:54 UTC
Hi all, In attachment a basic proof-of-concept patch for adding a firefox-like search bar to f-spot, with autocompletion. I know there is some kind of search bar attached to the Tag Selection Widget, but this implementation puts the search bar below the photo window. An approach worth considering? Suggestions are welcome: * is below the photos a good place to show a find dialog? * what kind of searches (besides seaching for Tags)? * ... Please treat it as "work in progress". The FindBox.cs file goes into the src directory. Best Regards, Thomas
Created attachment 53807 [details] [review] Patch adding basic find functionality
Created attachment 53808 [details] New Source file: FindBox.cs
I like the idea of the pop-up search bar, but I think it would be more appropriate to search images, not tags. The tags are listed in a TreeView, which automatically provides for "interactive searches" on it (and which was recently fixed to actually work, see bug #316051). It would be awesome if such a search bar could search the image (file) name, description, and other meta data. It could have autocomplete type affordances to make meta-data searching very simple (eg tab complete month/day/tag names). Smart auto-complete for specific meta-data looking entries (such as exposure, ISO, image size, etc) could be used so learning the "syntax" for querying based on such metadata could be painless. The less-elegant (IMO) solution would be a huge search dialog allowing the user to explicitly set each possible search field etc etc..but a search bar that just worked and was easy and smart would rock.
Created attachment 54980 [details] [review] patch adding findbar
I have taken Gabriel's suggestions into account and came up with a search bar that allows you to search for photo filenames and descriptions. The searching of tags has been removed. The find bar can be accessed with the 'f' key, like Nat's tagging bar can be accessed through 't'. I also tried to keep the look of the findbar and the tagbar consistent. As before, further suggestions / additions are still welcome! The new attachment makes the two older ones obsolete.
I actually disagree with gabriel on the tag search. Personally I would prefer the google-like search to the tags sidebar that doesn't scale very much. Search entry like the one in Rhythmbox or Banshee would be better than the in-document-like search that firefox/evince/epiphany have. The latter is more about highlighting a match in some content. This is more like filtering content.
Created attachment 55055 [details] [review] same as before, but find now works like banshee/rhythmbox search Patch that makes the findbar work like the banshee/rhythmbox find bars. I didn't change the position of the bar, and it is still accessed through 'f'
applying this on HEAD and trying to type f, doma quickly will crash right before typing 'a'. Typing it slowly will not crash. Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object in <0x00062> FSpot.PhotoImageView:HandlePixbufPrepared (object,System.EventArgs)in <0x00041> (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs) in <0x00056> FSpot.AsyncPixbufLoader:HandleAreaPrepared (object,System.EventArgs) in <0x00041> (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs) in <0x00093> GLib.Signal:voidObjectCallback (intptr,intptr) in <0x0002a> (wrapper native-to-managed) GLib.Signal:voidObjectCallback (intptr,intptr) in (unmanaged) 0xb6f6dab2 in <0x00004> (wrapper managed-to-native) Gdk.PixbufLoader:gdk_pixbuf_loader_write (intptr,byte[],uintptr,intptr&) in <0x0003f> Gdk.PixbufLoader:Write (byte[],ulong) in <0x000fc> FSpot.AsyncPixbufLoader:AsyncRead () in <0x00037> (wrapper delegate-invoke) System.MulticastDelegate:invoke_bool () in <0x0002e> FSpot.Delay:HandleOperation () in <0x00037> (wrapper delegate-invoke) System.MulticastDelegate:invoke_bool () in <0x0002a> IdleProxy:Handler () in <0x0002b> (wrapper native-to-managed) IdleProxy:Handler () in (unmanaged) 0xb7f4674f in <0x00004> (wrapper managed-to-native) Gtk.Application:gtk_main () in <0x00007> Gtk.Application:Run () in <0x00007> Gnome.Program:Run () in <0x003ca> Driver:Main (string[])
Next interesting question is the shortcut for this. My favorites are: * Ctrl+K (global/google search in firefox, it's also specced for the nautilus' beagle search, not sure if already implemented) * Ctrl+F (find in evince, epiphany, firefox) - may be the same problem as I've outlined above. Consistent behavior with the other apps would be selecting results, navigating through result hits, not filtering. But maybe it's more obvious/less evil than Ctrl+K
Created attachment 55065 [details] Screenshot Added screenshot on Gabriel's request. It looks like the crash Jakub mentioned, has something to do with the refresh not happening quick enough. Will have to study it :(
After more research, the version of the patch that works like banshee searching seems to crash quite randomly; and I can't seem to track it down. The only constant I can find is the fact that crashing mostly happens when you type quickly. Larry, could you have a look at this?
Created attachment 55291 [details] [review] Update fixing Jakub's crash New version of the patch, fixing Jakub's crash. Nothing else added, I first wanted to solve Jakub's problem, and maybe wait for more input. Thanks for checking out.
Created attachment 55907 [details] New version This tar contains a new version of the patch. Following changes have been applied: 1. findbar is now accessed through Ctrl-K 2. add timeout to the input field to prevent massive & unnecessary querying when user is typing fast. 3. improved the layout inspired by Banshee's search entry. Please comment.
*** Bug 323838 has been marked as a duplicate of this bug. ***
Relevant information about meny based search in Bug #139796
Why did you go with CTRL-K? To most people I think CTRL-F stands for Find. (Internet Explorer, Windows Explorer etc in the windows world for instance) CTRL-K might stand for Google Find, but what has Google to do with F-Spot?
I think it is worth considering making a search entry like this use beagle directly. I've put a fair amount of work into making beagle index image metadata including raw files (and will continue that work) and so leveraging it to search inside f-spot makes a lot of sense at least.
Just that I am not certain that we should build in a dependency upon Beagle. Will it always be installed? Will it search outside F-Spot as well?
The original comment/bug description asked for suggestions for what kind of searches should be possible. I think searching in the Exif tags could be usefull. For instance searching on Camera used og focal length. Sometumes I remember that I have taken a picture and I can remember that the focal length was high or the shutter time was fast, then it would be great if I could search on both the tags for the image and the exiftags.
Is this one same as bug #139796 - selecting multiple tags should limit query (use AND not OR) Especially in regards to Comment #30 from Thomas Van Machelen
No these pathces are not the same, but yes they are related. They are both attempts/experiments to add some kind of search bar to f-spot, because i think that searching through typing would be a great addition. Currently i consider the one at bug 139796 to be the most useful one, but maybe the different attempts can be integrated when the query branch lands into head. We'll see...
It's now landed, and includes a type-to-find bar, but it only searches tags. Renaming this bug to focus on adding the features that are missing - searching filename, description, time, etc.
*** Bug 380963 has been marked as a duplicate of this bug. ***
It would be nice to add searching of some standard tags as city, state, creator... For example: <dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/"> <rdf:Seq> <rdf:_1>Miloš Popović</rdf:_1> </rdf:Seq> </dc:creator
I guess the work started in here has stagnated. :-( Metadata (i.e. EXIF and other directories) and filename search really the cat's ass of this RFE I think.
*Push* Searching by filename would be really useful!
Personnaly I'm more interested by searching for EXIF metadata (focal, shutter speed, lens, camera ...) and I'd like to see this feature in F-Spot. An alternate way could be by importing EXIF metadata into F-Spot tags. This could be done when importing new files, and the list of EXIF metadata that will be imported should be configurable.
(In reply to comment #27) > Personnaly I'm more interested by searching for EXIF metadata (focal, shutter > speed, lens, camera ...) Yeah, having just gone through a process where I used external tools to find all of the photos by camera type so that I could fix the incorrect time stamps from a handful of different photographers of a single event, I can concur that being able to search for exif tags in f-spot would have been much sweeter. As it is now, I have tags for the different cameras and all photos have a "which camera" tag on them now. > and I'd like to see this feature in F-Spot. Ditto. > An alternate way could be by importing EXIF metadata into F-Spot tags. This > could be done when importing new files, and the list of EXIF metadata that will > be imported should be configurable. Indeed. Interesting idea. Implicitly adding tags to photos for exif data. In addition to having a configuration item about which exif data to create tags for, if one adds a new exif data item to create tags for, f-spot should scan all existing photos and fill in that new tag for them. Or perhaps this exif tagging should always only be done on selected photos, which could include the current import set. Maybe a UI flow such as: select photo(s)->create tag->for exif->choose exif items to create tags for.
(In reply to comment #28) > (In reply to comment #27) > > Personnaly I'm more interested by searching for EXIF metadata (focal, shutter > > speed, lens, camera ...) > > I can concur that > being able to search for exif tags in f-spot would have been much sweeter. i'd also like to have this feature in f-spot > Maybe a UI flow such as: select photo(s)->create tag->for exif->choose exif > items to create tags for. interesting idea
One more vote for filename search (including full path)!
F-Spot has moved to https://github.com/f-spot/f-spot/issues If this Bugzilla ticket is still valid in a recent version of F-Spot, please feel free to post this topic as a ticket in the F-Spot project on GitHub. Closing this report as WONTFIX as part of Bugzilla Housekeeping as we are planning to shut down GNOME Bugzilla in favor of GNOME Gitlab.