match entire string when autocompleting tags
Submitted by an unknown user
Link to original bug (#716765)
Description
---- Reported by shotwell-maint@gnome.bugs 2010-10-06 07:07:00 -0700 ----
Original Redmine bug id: 2652
Original URL: http://redmine.yorba.org/issues/2652
Searchable id: yorba-bug-2652
Original author: Masin Al -Dujaili
Original description:
I have some suggestions for tag handling.
- Allow nested tags, e.g.
persons/mother
persons/father
persons/my first dog
etc.
In tag overview, tags beginning with 'persons/' should be presented as a 'folder'. To simplify adding (and modifying) tags, tag edit could display a folder tree with checkboxes. This view should be saved in its state across multiple taggings to have the last position of the tag tree displayed.
- Improvement of tag autocompletion
When entering tags, autocompletion should not only search from the beginning but everywhere. Typing 'sun' should find 'sunrise' as well as 'glaring sun'.
I hope you'll find some ideas worthy considering :-). I like your program a lot.
---- Additional Comments From shotwell-maint@gnome.bugs 2010-11-07 09:28:00 -0800 ----
History
Comment 1
Updated by Adam Dingle about 3 years ago
-
Priority deleted (
<strike>
_Low_</strike>
) - Subject changed from nested tags and tag autocompletion to match entire string when autocompleting tags
MasinAD,
I'm glad you like Shotwell!
Thanks for your suggestions. (In general, it's a good idea to file a separate ticket for each suggestion so that ideas can be tracked independently).
Your first suggestion is a duplicate of#1401, one of our most popular feature requests. We're planning to implement this for Shotwell 0.9, which will be released early next year.
Your second suggestion is a new idea. I'm renaming this ticket to reflect that suggestion only.
Comment 2
Updated by Marcel Stimberg about 3 years ago
A simple match (match everything that contains the typed characters) would be trivial to implement – but is this really useful? That would mean as soon one types “eâ€, all tags containing an “e†would appear… Maybe only match the beginning of words within a tag (e.g. “s†would match “sun†and “glaring sun†but not “lightsâ€)?
Comment 3
Updated by Masin Al-Dujaili about 3 years ago
Replying to [comment:3 marcel]:
A simple match (match everything that contains the typed characters) would be trivial to implement – but is this really useful? That would mean as soon one types “eâ€, all tags containing an “e†would appear… Maybe only match the beginning of words within a tag (e.g. “s†would match “sun†and “glaring sun†but not “lightsâ€)?
That might work well with languages that don't know compounds as english, but it wouldn't work with languages that do, like german, where you can build words like Donaudampfschifffahrt (Donau steam ship travel). At least, a configuration option might be useful to switch between 'match all' and 'match any word'. Other languages have even more obscure features, e.g. cases modifying the beginning of nouns, depending if it's nominative, genitive, accusative, dative or ablative case. I think irish is such a language.
If I have just a few dozen tags, I'd nonetheless type more than one letter to limit my choices to just 2 or 3. While typing, it's more efficient to type another letter, thus reducing from 20 to 4 choices, than hitting [UP] or [%(=caps)DOWN%] many times to select the wanted tag.
Sorry for my english, I'm quite out of practice :-). Oh! And sorry for the duplicate. I looked at the active tickets and searched for 'tag' but didn't find anything halfway matching.
Comment 4
Updated by Jules Kerssemakers about 3 years ago
Seconded!
For reference, here's some solutions to many-autocomplete-options I've come across over the years:
- a short timeout (e.g. 300 ms) after the first character was typed before starting the search. Usually the user will have typed more characters by then if he knows what he wants, limiting the amount of search results. If the user really wants everything for “s†he'll wait after typing it, and expect a ton of results
This could be partially alleviated by matching only at start-of-word (the “Sunâ€,“glaring Sunâ€,but-not-“lightS†idea)
- start search immediately after first character was typed (returning e.g.
- results, but only display the first 10 most-used/most-recently-used, with an 11th, greyed-out item saying “116 more tags not displayed..â€.
in most cases, the desired tag will be in the top-10, and if the user wants a tag not there, he'll usually know which one, so it's easy for him to give more characters to narrow the search.
- The one used in gnome-do: (my personal favourite)
return all tags which contain the typed characters in that order.
E.G. searching for “ff†returns “FireFox†(matching chars bolded/uppercased), but also “stuFFingâ€. In this way searching “ddsf†would also find “DonauDampSchiffFahrtâ€, giving a very intuitive way for users to find compound-tags: just type the first letter of each word.
The result-ranking is (I believe) based on most-used. but for Shotwell should probably be based on “most recently appliedâ€.
--- Bug imported by chaz@yorba.org 2013-11-25 21:47 UTC ---
This bug was previously known as bug 2652 at http://redmine.yorba.org/show_bug.cgi?id=2652
Unknown Component Using default product and component set in Parameters Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution