When selecting in the text field of a category, usually the list shown below is shortened so that all entries with matching letters are shown. This fails when the category entries contain blanks. See attached image (montage of two subsequent input steps): Enter "F" - all names starting with F are shown Enter "Fr" - all names starting with Fr are shown (left half of image) Enter "Fr." - list is empty (and does not fill again if more is input - right half of image) The entries contain a lot of names like "firstname lastname" or "Fr. Müller" (a.k.a. "Mrs. Miller"). The empty list is always shown when the next letter would be a blank in one of the entries. (I already saw the error in some 4.6.x-git-revisons and it was OK in older versions) Reproducible: Always
Created attachment 98075 [details] montage of two input steps in the annotation dialog (screenshot)
Created attachment 98076 [details] same dialog on ancient version 4.1.1 was still ok The second screenshot shows the same dialog (on the same database) accessed from a virtual machine with KPA 4.1.1 on openSuSE 12.2. Here the refinement works across the blank (Enter "Fr. H" shows a list of all "Fr. H*" entries below.) This is how it should be. Sorry, that I cannot boil it down to a narrower range of revisions. I remember, this issue has been around for quite a while, but other issues took precedence (and have been fixed in the meantime :-).
Thanks for reporting this, I can confirm this behavior with current git master. I'll have a look at it as soon as possible. This surely is a regression.
Okay, after some quick investigation: "It's not a bug, it's a feature™" ;-) When opening the annotation dialog, you can click "Options" at the bottom and choose how tags should be matched. You can choose from: - Match tags from the first character - Match tags from word boundaries - Match tags anywhere The default seems to be "Match tags from word boundaries", which will always result in an empty list when some search term with a space character is entered, as the tag names are split up by whitespace and matched against the entered text afterwards (and thus, no space can ever be found there). E. g.: If we have "Fr. Müller", it's split up to "Fr." and "Müller". As soon as your search string becomes "Fr. ", it neither matches any of them because it contains a space at the end. If you switch to "Match tags from the first character", you get your desired behavior. Probably, this wasn't there in KPA 4.1.1, so it "simply" worked there. If of if not this is a meaningful thing to do or if this could be a bit smarter is another question …
… of course: feel free to re-open this if I'm wrong!
I have to admit that I was the one introducing this behaviour. As Tobias described, it should not be an issue if "match from first character" is selected. I'm reopening this because it is on my "minor annoyances to fix some day" list, as well.
OK, You caught me (again!) with not investigating the options closely enough... Thanks! I tried and succeeded. It even works, when I change the default and then, in another session, open a different database. Maybe it would be easiest to change the default and leave it at that. However, as this seems to be one of the central KPA settings (~/.kde4/share/config/kphotoalbum.rc ??), this default will only work as such for new users or people who clean up their rc-files. [On the other hand: I did not find this setting in the rc-files...(??)] Right now: "Works for me. ™" Let's add some explanation (found by means of experimental informatics): - Match tags from the first character: regex: /^search_string/ search a left justified string This is, how autocomplete works in the most natural way. - Match tags from word boundaries: regex: /\Wsearch_string.*\W/ search a string left justified at any word boundary - cannot search across word boundaries If you need to find last names. - Match tags anywhere: regex: /search_string/ search any string anywhere This is most useful for people who use the input field knowingly as a search field.
Just fyi: With commit 950ebb8, I added a possible "fix" for that that changes the search behavior. If we search with word boundaries, the search term and the tag names are both split up to words and all tag words are matched with all search words. I think this leads to a "less surprising" behavior, as when you search for "Fr. Mei", you get "Fr. Meier", and you can also search for "Mei Fr.". Johannes didn't comment on this commit yet, but I like it ;-)
@Tobias: my build process is really errorprone right now, because every now and then some system updates upgrade some libs to QT5. Therefore, I will keep my 4.7.1 for now, until I run into real problems or the switch to QT5 is done in KPA and all dependencies. (I hope this upgrading in the background does not break things.) Thus: no testing for me right now, sorry! Your idea sounds appealing to me. It will be a bit more tolerant then simple string search and this might be a good thing.
This bug should be fixed since 950ebb8.