SUMMARY see $SUBJECT STEPS TO REPRODUCE 1. group some images, collapse the group 2. search for an image _contained_ in the group by filename 3. open the group 4. search again OBSERVED RESULT after 2: image not found after 4: image found EXPECTED RESULT image inside group should be found in any case To be more specific: - items matching a search term should always be displayed even when collapsed inside a group. - But when a group parent matches, the search should NOT show all items behind this group as well just because the parent matched. Using Digikam 7.2 appimage and KDE Neon 20.04 with all updates applied.
We have discussed this very often and had bug reports about it, some users want to find the items in the group, others don't. If you want to find items in the group, we have created the option to display all groups as open in the menu-> view. Maik
I think we are talking about two different situations. All the discussions I heard about so far were about the question "Do you want to find grouped items when the *parent* matches a search term". This is debatable, and this is what all past debates were about. (I also wrote a bug report regarding the display of grouped search results). But I honestly cannot imagine a use case where it makes sense to skip *exact* search results just because the VIEW settings of the icon view are currently hiding them. If this is really intentional, then the question of whether groups are open or closed does not belong into the "View" menu, because it has influence on other parts of the app as well. If you want to make this explicit, add a checkbox / option in the search results "Include closed groups", but I think this would only add to the confusion. So, IMHO: - Do not include group children just because the parent matches. - But DO include group children which match precisely. - In both cases, the view state of the group should not matter, otherwise it would not (just) be a "view" state.
First of all, for the search it doesn't matter if the group is closed or open. The items are treated like everyone else. Whether the items found are displayed or not is a filter of the view. Group open-> displayed, group closed-> hidden. There will be no other solution here. The option to add to the search has also already been discussed. It would then have to be available for all virtual albums. Maik
We also have to fulfill the wish of users who, even in the event of a match within the group, do not want to be displayed when the group is closed. Maik
> First of all, for the search it doesn't matter if the group is closed or open This is not true, and that's what my bug report is all about. If a group is closed, exact search matches inside the group won't be found. Use case: I want to know where, if anywhere, a specific image exists in my library. I don't care if it's grouped, tagged, hidden or whatever. I just want to find it. The search tool doesn't do the job properly in this case, if this behaviour is intentional. One would have to walk through all albums and open all groups manually to *really* find all matching images. And this can't be the solution. To indicate that the item is inside a group, but the group parent doesn't match the search parameters, one could e.g. show the group parent with 50% opacity, and be able to open it to reveal the matching child. Just an idea ...
You only need to activate the option in Menu-> View to display all groups "virtually" as open. And this option can also be switched on / off after a search. Then all the desired items will be displayed in the search. That's all... And other users can still "hide" the images in the group. The solution might be a bit confusing, but it was found to be good by the other users. If you want, I'll pick out the old bug reports for you. Maik
You don't need to go through all of the albums and manually open the groups. This is done by an option in the Menu-> View. All groups are displayed "virtually" as open, across the entire collection. And yes, technically the search doesn't care about a group. It is a filter of the view whether the items are displayed. Maik
*** Bug 438029 has been marked as a duplicate of this bug. ***
Could this problem be solved if the Show All Group Items As Open menu is just a view solution. And at the same time generate Right-side Filters new grouping options. For example: 1. Show full group members (default). 2. Also show group members in the search with a partial match. 3. Show only the top members of the group 4. Do not show groups. This is just an example - other desired options could be offered under the filters if necessary. The need for such a solution arises because users do not just want to form groups based on date or file similarity. I have formed groups: image + text on the back of the image. All options for forming a group can be good at some point. Subtracting the above functions gives the user clarity on what to expect from the program. Hannes
Thinking further, I wondered whether groups should be listed under similarities and searches. They often contain different images. Even when grouping by image name, it is possible to find completely different images of the same name from different periods with large collections. In the search for similarities, there are problems with displaying such groups because the group contains partly similar and partly dissimilar images. Non-similar images cause similar images not to be displayed. The solution could be not to show groups in left-hand searches, except for albums. It could be switched on and off according to the user's taste, because sometimes groups work very well. It should also solve the problem of the topic initiator - since groups are not taken into account if necessary - the search always works. Hannes
*** Bug 458880 has been marked as a duplicate of this bug. ***
@Jens digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
(In reply to caulier.gilles from comment #12) > @Jens > > digiKam 8.0.0 is out. This entry still valid with this release ? > > Best regards > > Gilles Caulier yes problem still present. when all group are collapsed , the result of a search report 3 files when flag show all group as opened is set , the same search report 58 files
Jens, What's about this file using current 8.2.0 AppImage Linux bundle ? It's reproducible ? https://files.kde.org/digikam/ Thanks in advance Gilles Caulier
I have been pulling my hair out over this. I couldn't understand why searching for images with terms that I knew it should be enough to show them in a search, it didn't. The state of grouped images should not play a role in search results because it clearly gives the wrong information. I like to have my groups collapsed. But when I search for images, I expect that all images with the terms I've searched would be shown. Otherwise, the message I receive is that the images I've searched for are not there. And since I like having my groups collapsed it's not practical to keep toggling on and off this option just to make a search. Not to mention that a new user would not know about this. I can't remember how many hours I've lost trying to find images that I knew I have put in digikam before, but searching for them, some days/months after, I couldn't find them. At least make it an user option (for the search function) and/or display a popup message that informs the user, in every search, about images not shown and how to show them. Maybe provide a toggle, like a check mark, on the top of the search results along with the message. This check mark of course should be temporary and only affect the current search results and not the main setting of how the user wants the groups to be shown.
I agree completely, and yes, this is still an issue with the current Appimage.