| Summary: | Searching for tag names in simple and advanced search doesn't work | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Andi Clemens <andi.clemens> |
| Component: | Searches-Advanced | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | marcel.wiesweg |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 0.9.4 | |
| Sentry Crash Report: | |||
| Attachments: |
fixes search problem
patch 2 patch 3 |
||
|
Description
Andi Clemens
2008-06-04 20:52:53 UTC
Created attachment 25124 [details]
fixes search problem
This patch fixes the following issues:
* simple and advanced search doesn't work for tag names
* lineedit widget in advanced search will expand, it was too short if window is
resized
* not needed search conditions are removed (searching for Tag doesn't need the
condition "contains" for example)
Gilles, Marcel, Arnd,
what do you think? Can I commit this?
Andi
I've found another problem: When editing an advanced search that has not any search rule with a lineedit field in it, the operator combobox becomes too small. If you edit a saved advanced search with a lineedit rule (like Tag name for example), the combobox is sized well. I will also try to fix this issue with this patchset. Additional info to #2: If you generate a new advanced search, the operator comboxbox is always sized well, only saved advanced searches that are edited will behave strange sometimes. Created attachment 25133 [details]
patch 2
the patch fixes the following issue:
some items in the operator combobox were not readable, because the box was
resized on key change. Now the box is prepopulated with all operators first and
the size is saved on every key change.
Andi, This is relevant of this old entry (closed with KDE4 port) : http://bugs.kde.org/show_bug.cgi?id=147636 Gilles Sure it might be fixed in KDE4 port, but not in the current stable version of digiKam. But the initial problem of this bugreport is not the widget behavior, but the search for tag names which didn't work anymore. The patch should solve this problem... Andi, Why are you removed "LIKE" and "NLIKE" rules for tags searches ? Gilles It looks like they are never used. If you search for a tag, you have the exact tagname in the combobox and there will never be a query for LIKE or NLIKE. Like in album search. The only two operators allowed in there are EQ and NEQ. So I removed the LIKE and NLIKE for tags from the rulesOpTable as well as from the kioslave (digikamsearch.cpp:489). Searching for LIKE and NLIKE in "tag names" is still possible... but for "pure" tag searches I think it should be removed like it is removed in album search. Marcel, what do you think about #8 Gilles Ok, removing LIKE is wrong, if you want to find all images with a tag under "persons" (persons/andi, persons/gilles) you will need to have LIKE and NLIKE operators. But then it should also be added to album search, because otherwise it is inconsistent. Created attachment 25139 [details]
patch 3
fixes the following issues:
* simple and advanced search doesn't work for tag names
* new operators for album search added (LIKE, NLIKE)
* lineedit widget in advanced search will expand, it was too short if window is
resized
* some items in the operator combobox were not readable, because the box was
resized on key change. Now the box is prepopulated with all operators first and
the size is saved on every key change.
Marcel,
> * new operators for album search added (LIKE, NLIKE)
==> is implemented in KDE4 ?
Gilles
Gilles,
I think it is implemented, I just tested the KDE4 version and LIKE for albums is definitely working there. If you select a folder ("2001"), it will search recursively.
In KDE4 I have called it InTree/NotInTree, and it's currently even the default behavior for the combo box tree views for albums and tags. Is it not possible anymore in the KDE4 version to use the "NOT" operators? Like "does not contain" or "does not equal"? I try to filter images that have NOT the tag "Persons" and that are NOT in folder "2007 and its subfolders". But there is no option in the new search dialog of digiKam 0.10... maybe I'm blind. Marcel, what do you think of the new operators added in patch 3? I think they should be added to be consistent with the tag search. No you're not blind. It's currently not in the UI. The backend can do that without any problem. It is the problem to balance search capabilities with UI complexity. The least complex solution would be to add "Match none of the following conditions" in the label at the top. You could then add a search group for all "NOT" searches. As to your patch, feel free to add the operators. SVN commit 817988 by aclemens: fixes the following issues: * simple and advanced search doesn't work for "tag names" * new operators for "album" search added (LIKE, NLIKE) to be consistant with "tag" search * lineedit widget in advanced search needs to expand, it was too short if window is resized * some items in the operator combobox were not readable, because the box was resized on key change. Now the box is prepopulated with all operators first and its size is restored on every key change. BUG: 163227 M +2 -1 NEWS M +18 -9 digikam/searchwidgets.cpp M +12 -5 kioslave/digikamsearch.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=817988 |