GNOME Bugzilla – Bug 139796
selecting multiple tags should limit query (use AND not OR)
Last modified: 2006-10-24 21:35:28 UTC
The behaviour today is that no selected tags mean show the whole library. Then I'm allowed to select a particular tag which limits the selection to only images with particular tags. But selecting another tag starts to add to the selection, because it effectively means show images that include one OR the other tag. This doesn't look consistent. While I agree such querying will be useful, the existing query interface should use the AND operand. That will further limit the selection. Show only images that include both tags, first AND second. There should be some advanced query dialog in future to be able to specify more sophisticated queries.
I see the reason for this may have been nesting. When you select a category, all the child tags are selected. I would favour keeping the behaviour of using OR for all the child tags when selecting a category. But I'd keep the child tags unselected. But looks like this would need some user testing.
Created attachment 32855 [details] [review] AND tags and categories I previously sent this patch to the list 1. Make so you can select tags and categories independently of each other 2. Shows photos that only have all the selected tags 3. A photo is considered to "have" a tag if it, or any of its children are attached to it. The most common use is to pick a couple of leaf categories. E.g. all photos with person 1 and person 2. Or person 1 at place 2. But if you nest your categories in a subtyping relationship it allows you to do more complex stuff. I have Places -> Country -> City (imagine GPS enabled cameras). So I can ask for all photos of my nephew taken in Scotland, for example. The implementation in the tag is a bit weak (I can get it to crash sometimes if I end up with no pictures matching). It serves the purpose of illustrating the concept.
There is a function in that patch called MeAndAncestors which is the wrong name. It returns all tags that have that tag as an ancestor.
*** Bug 168447 has been marked as a duplicate of this bug. ***
I also expected an AND behaviour when using f-spot, and was surprised to see OR. If the patch that Loz has posted is working, can you incorporate it in f-spot ?
*** Bug 306962 has been marked as a duplicate of this bug. ***
My instinct was to OR the selected tags within a category, then AND them with the OR'd selected tags of other categories. For exmaple, you have Places - Kansas - New York - Illinois People - Me - Larry - Luis You could see pictures of (Larry or me) in (New York or Illinois). I understand users could intend (Larry and me) in (New York) ... but allowing that and the above example would entail significant changes to how these filters are selected. The first approach makes more sense to me, because you can OR tags of any type, but ANDing will often not make sense (Places, Photographer, etc). The current approach of ORing all selected tags across all categories seems the worst of the options, since it has no ability to show pictures that match two or more tags. Perhaps a long-term solution that could provide much greater flexiblity would be a text-entry where the user can write out what they want to see, as in "Pictures of Larry and Gabriel taken by Luis in New York or Illinois but not Chicago." With content-assisted popups and graphical goodies, of course. :) Add speach recognition..and that's enough for one night.
Interesting, related commentary happening on bug 170315.
I also think that the default behaviour should be "AND" behaviour, especially across categories. Imagine I want to see all pictures that include both my parents in my hometown, I'd select "Mom" and "Dad" in People, and "Eindhoven" in Places. Right now, I get all pictures that have either a tag with my mom, my dad, or Eindhoven, which is were I took a lot of my pictures.. exactly the wrong behaviour. For places, it would make sense to use OR selection, because you usually won't tag a photo with more than one place. With people, it's -not- logical. I can imagine a filtering system much like the E-mail filters in Evolution or Thunderbird, where you can filter based on Name, Date, etc, and choose whether you want items that match "Any of the tags" or "All of the tags". Of course, this would require an extra dialog.
*** Bug 315930 has been marked as a duplicate of this bug. ***
Created attachment 53006 [details] [review] TagLogicQuery Patch Since actions (including dragging and dropping, double clicking, right-clicking, and traversing menus) speak louder than words, I've implemented what I was imagining for the tag querying. This is the patch I sent to Larry a while ago, hopefully it still patches CVS cleanly. You'll need to un-tgz, apply the patch file, and move the two .cs files into src/ and the image into in icons/. Some ways of making the functionality more discoverable include defaulting to showing the query bar, including "include" and "require" buttons instead of the single checkbox or putting those buttons on the toolbar. I will post an image of this patch in action next.
Created attachment 53008 [details] Screenshot of logic query widget in action In this screen shot you can see I've searched a photo gallery containing a bunch of background images for (Places AND People) OR Animals. This screenshot doesn't do the interactivity of the querying justice -- you can drag and drop tags to change the query, and "include" and "require" tags via the context menu and the Tag menu. And of course there isn't a limit to how many tags can be ANDed or how many AND terms can be OR'd together...it's very flexible and powerful, including negating tags.
Created attachment 54566 [details] More complicated screenshot This is a screenshot of the same patch that shows a more complicated query (including use of the NOT operator).
I agree that the observation that selecting two tags should result in the intersection of images with those tags. (i.e. Selecting "Fall" and "Vacation" would only return images containing both of those tags) This is the most intuitively obvious for the user, and should be the default. The logical OR queries should be moved into an Advanced Search dialog, which can facilitate building of many other complex SQL queries. I have attached a patch to enable AND/INTERSECT as the default behavior.
Created attachment 54661 [details] [review] patch to enable AND/INTERSECT behavior by default
I've posted a screencast demoing the functionality provided by my query patch. The screencast is made with vnc2swf, meaning the output requires a Flash plugin -- very sorry about that, I couldn't get istanbul to work. http://www.ews.uiuc.edu/~gburt/f-spot/f-spot_query.html In it you can see arbitrary queries constructed of AND, OR, and NOT operators, and drag and drop query construction. You can also change the query via the context menu of tags (and queried 'terms') and via the Tags menu. Two additional (unimplemented) ideas could address both the discoverability issue and the power-user (who doesn't want to drag and drop..) issue: We could put two or more buttons at the top of the tags TreeView that would provide Include, Require, and perhaps Filter (which would NOT a tag) functionality for the currently selected tags. And, we could make those constructors available via an interface similar to Nat's tag-typing feature. Feedback and suggestions regarding this interface are greatly appreciated.
Nice idea, Gabriel!!! Hope to see it implemented soon! :-) Marco
Gabriel's patch seems like the most flexible approach. Has anyone considered moving this into CVS? If not, is there an outstanding reason why it shouldn't be included?
Good idea, but I think we risk overcomplicating it. Tags across TOP LEVEL categories should be AND'd. Tags across anything else should be OR'd. If we want fancy things like exclusion - we should move this to an "advanced filter" thing. I just showed this app to my Mum, I don't want to see her faced with confusion - like in the Flash demo I think you double click the filters and they add to the "find" bar. Don't get me wrong - it's a nice idea, but it's FAR from intuitive. Tick boxes, however, are simple and make sense. Maybe make the tag filter thing switchable from Simple mode to Advanced mode, then do all the fancy trickery you want in Advanced, but leave us with simple check boxes in Simple. So, in summary... read my second paragraph, and do all the fancy boolean expression building stuff in Advanced mode.
The checkboxs on the left are intuitive...but there is a limitation. If I select the tag "Friend" all sub-tags are selected, for examples "Davide" "Mimmo", "Angelo" etc...OK this is the default behavior... But if I want to see my friends photos but no the "Davide" photos (for some reason)? At the moment I can't de-select the "Davide" sub-tag...It will be very useful, and it's tha aspected behavior (I click on a selected checkbox and It should be deselected).
Gabriel's patch seems very intuitive and simple to use, unless there are serious objections to it i would like to see this make its way into cvs soon.
*** Bug 170315 has been marked as a duplicate of this bug. ***
Created attachment 57697 [details] New version My patch is in CVS in a branched copy of f-spot. You can check it out with: cvs co -r F_SPOT_QUERY -d f-spot-query f-spot It is sporting a brand new Find menu way of accessing all the features (screenshot attached). It also supports tags without icons. The main thing left to do is to make the tag context menus better. Everybody is encouraged to do a checkout of this branch, test it out, and send feedback and/or patches.
don't take me wrong but i think this is not the best approach. I think that having to go trough a lot of menus is not the best thing to perform a search. I like very much rhythmbox or jamboree example where the search is done in real time writing some text into a box and if you happen to want a more powerful approach they also support AND OR and NOT operators. The default search could look in the image exif comment tag (or however it is called), file name and tag automatically without requiring writing any complex expression. Just like rhythmbox does (it looks in all the relevant ID3 tags - author, disc and song name -).
Actually, I would agree with Diego. If you look at Amazon, you just enter a search word, and it will do its best to find the corresponding book for you, no matter if it is a ISDB, Title, or Author you entered. Much easier for the end user (my mother for instance) if it is possible to simply the input. Perhaps a simple command line entering (with AND, OR, and NOT) and searching through all tags, with a gui as a backup?
Similar, but with text based search, in bug #319556
Gabriel's patch looks great to me. If we need text as well, then fine. The current or-everything-together approach is possibly the least useful default I can think of, excepting maybe the "randomly show images" one :)
Woot! Need to have this! Candy. And Pony. Need candy and pony. (Nevermind I am just ccing myself here :)
*** Bug 336907 has been marked as a duplicate of this bug. ***
Created attachment 64785 [details] [review] Patch adding search bar This patch has been sent to the mailing list also, just adding it here make sure it doesn't get lost In attachment you can find a patch against the F_SPOT_QUERY branch of f-spot. It allows you to search for photos based on their tags. The search bar can be accessed by pressing 'f' in the main window. Some searching examples: * Events Places : gives you all photos that have both the Events and the Places tags * Events OR Places : gives you all photos that have the Events tag or the Places tag, note that the OR operator must be uppercase * Events Places OR People : gives you photos with events and places tag OR photos with the People tag. Also the find entry re-uses the code of Nat's tagging patch for autocompletion. So if you type "Ev" and press tab, the text will be expanded to "Events". This patch is against the F_SPOT_QUERY branch because it allowed me to easily implement the AND/OR logic. (Good job, Gabriel!) Feedback is greatly appreciated...
Thomas, I looked at your patch and tested it out, it works pretty well and I think it will make a good addition to the query branch. I'll send you a more thorough review soon and we'll get it committed.
Any news on when the Query branch can be committed?
Related bug in bug #138065
So, here is a first impression and some GUI thoughts from a guy, who just installed f-spot v1.3 (ubuntu breezy). Disclaimer: I am no developer although I have theoretical programming knowledge. Therefore, all comments are strictly user perspective. :-) Having read your discussion, I just tried it out... I agree with the ones favoring the AND default for filtering. Users browsing through photos are creating queries like "<persons> at <place> during <time>" in most cases. And that is AND. I guess that a query like "<me> OR <Rob> in <place>" are very rare. Then the user will remember the <place> and only search for that. And by having AND the default, she can simply refine the research by ticking/adding categories. If I select a categorie, all sub categories get marked (= OR) and displayed, which I'd say is expected behavior. The user expects that when clicking on <places> all places will be shown. But then, it should be possible to deselect subcategories, say, to exclude, <Munich> from all places. Gabriel, I like your graphical filtering a lot! Of course, offering AND, OR and NOT can lead to quite complex expressions, but that is not against your approach. Users can use Boolean logic in a google search as well -- and only few actually use it (to its max). I also think that a menu-based filtering will not be well-received. (I just explained my father on the phone how to add an icon to the toolbar under KDE... 4 layers of context-sensitive menus... We did not manage.) I hope that was somehow useful and I am really looking forward to the upcoming updates of f-spot! Thanks for a great app! :-)
I've posted to the f-spot-list about how I've brought my branch back into line with HEAD and fixed some things up. Please see http://mail.gnome.org/archives/f-spot-list/2006-August/msg00028.html
Created attachment 71187 [details] Animated GIF showing the text-entry find bar I've committed a find bar based on some of the ideas from Thomas's ideas/patch. It is in the F_SPOT_QUERY branch. It doesn't do the NOT operator yet, but it does have some nice features like tag-name completion, automatic closing parenthesis, and tab'ing to move between terms quickly.
> Users browsing through photos are > creating queries like "<persons> at <place> during <time>" in most cases. And > that is AND. I guess that a query like "<me> OR <Rob> in <place>" are very > rare. Then the user will remember the <place> and only search for that. Was that supposed to be "<me> OR <Rob> in <persons>"? I'm in favor of AND'ing top-level categories and OR'ing everything else. That seems most reasonable. Otherwise, AND'ing everything would be okay. That makes it easy to get "All pictures with both me and Rob..." but makes it impossible to get "All pictures with me in New York or London." By OR'ing the non-top-level things, you get the pictures you want and some you don't want. If we AND them, you will not get all the pictures you want. Therefor, I think it's best to OR them and allow the user to manually deal with things at that point...
I just checked the F_SPOT_QUERY branch and one thing I noticed: Ctrl-F only works, when you are in the main window, not when focus is in the tag sidebar. IMO Ctrl-F should work everywhere, when you are in browse mode. But I don't know, if this can be done easily...
Hi. Don't blame me if something does not work, I am pretty new to F-Spot. Due to my needs, I have joined both F-Spot-Query and SpeedyDuplicates2 (originally at http://bugzilla.gnome.org/show_bug.cgi?id=169646). I attach the patch. Please understand that this is my first patch, hope it works to you, too. Moreover I have written a small script that helps building under Ubuntu, partially solving bug #351522 (http://bugzilla.gnome.org/show_bug.cgi?id=351522). Comments are welcome. Marco
Created attachment 71804 [details] [review] Patches F_SPOT_QUERY adding Find Duplicates functions.
Thanks for the feedback, Fabian. I have fixed it so ctrl-f should work from anywhere now. I have also made the tag find bar (the graphical one) and the text entry find bar mutually exclusive. If you use one, it will make sure the other is hidden. Hooking them up is a possibility, but too much work for too little gain for now. As Fabian noted, ctrl-f now shows the tag find bar (as does Find -> By Tag), and / and ctrl-shift-F shows the text entry find bar.
Hi, I have just been testing the query branch and would like to say it seems very useful to me. It worked fine with the queries I tried. There was one little issue though, I had the text query open and pressed ctrl-f for the graphical query and it locked the program up and all I could do was force it to quit. The console gave no error messages other than Killed.
The duplicate patch does not belong here. Kevin, can you repeat the crash/freeze? See http://banshee-project.org/Debugging
At long last, the query branch has been committed to HEAD. Thanks for all the input and hard work. Please test and submit new bug reports for any issues you find with the new functionality. Thanks!
Sorry Gabriel I missed your reply, Just to let you know it does not crash for me any more. Thanks.
(In reply to comment #45) > At long last, the query branch has been committed to HEAD. Thanks for all the > input and hard work. Please test and submit new bug reports for any issues you > find with the new functionality. Thanks! > Does the latest release of F-Spot (0.2.2) has your patch?
Yes it does. Check http://f-spot.org/News