Bug 185106 - Advanced search is not saved/restored correctly
Summary: Advanced search is not saved/restored correctly
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Searches-Advanced (show other bugs)
Version: 0.10.0
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-21 11:17 UTC by Andi Clemens
Modified: 2019-12-28 06:22 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.0.0
Sentry Crash Report:


Attachments
wrong options (227.02 KB, image/jpeg)
2009-02-21 11:22 UTC, Andi Clemens
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andi Clemens 2009-02-21 11:17:29 UTC
Version:           0.10.0 (using 4.2.00 (KDE 4.2.0), Arch Linux)
Compiler:          gcc
OS:                Linux (i686) release 2.6.28-ARCH

When I save an advanced search and edit it again, some options are displayed wrong. Also advanced search doesn't seem to work in general, I will explain later...
Comment 1 Andi Clemens 2009-02-21 11:22:23 UTC
Created attachment 31515 [details]
wrong options

This screenshot shows the differences.
On the left is the screen when I first created the search.
On the right is the screen when I edit the search.
As you can see, the matching conditions as well as the logical conjunction between the two groups changed.

But this is not the only issue. When I create the above search, it doesn't work as expected. I wanted to create a search where images are returned that have neither tag A nor tag B in it. But I always get images with only tag A assigned to them.

Another example: If I create a search like this:
(all conditions met: search all albums: tag A) AND
(all conditions met: search all albums: tag B)

I still get only the images with tag A assigned to them.
Something is broken here...

Andi
Comment 2 Andi Clemens 2009-02-21 11:27:40 UTC
1. Another note on the advanced search dialog: I think it is way too big.
We should at least put every search group into a tab, it is so hard to read.

2. Why does the first group header has a different arrangement of the conditions than the second? These headers are wasting a lot of space anyway.

What do you think? Although there is a huge blue header, I still find it hard to distinguish between the two search groups.
It would really help to have tabs here, mainly because a single search group itself can be 2 pages long, when every category has been expanded.

Andi
Comment 3 Marcel Wiesweg 2009-02-21 17:42:47 UTC
SVN commit 929571 by mwiesweg:

Simplify: complex and buggy code is not necessary here (other parts are complex enough)

CCBUG: 185106

 M  +1 -14     searchgroup.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=929571
Comment 4 Marcel Wiesweg 2009-02-21 17:42:52 UTC
SVN commit 929572 by mwiesweg:

Add missing implementation for "OrNot" (which was not properly written or read as a consequence)

BUG: 185106

 M  +5 -0      searchxml.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=929572
Comment 5 Andi Clemens 2009-02-21 18:05:09 UTC
There is still a problem:
When I edit a saved search, the changes go into "Current Search", not the one I edited.

Andi
Comment 6 Marcel Wiesweg 2009-02-21 18:11:23 UTC
SVN commit 929591 by mwiesweg:

Backport:
Add missing implementation for "OrNot" (which was not properly written or read as a consequence)

CCBUG: 185106

 M  +5 -0      searchxml.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=929591
Comment 7 Marcel Wiesweg 2009-02-21 18:31:28 UTC
Works for me. I select any stored search except Current/Last Search, click on Edit Stored Search's Edit button, edit, click ok. The stored search is edited, Current/Last Search is untouched.
Comment 8 Andi Clemens 2009-02-21 18:44:47 UTC
I recompiled everything again (make clean) and now it seems to work here, too.
I will watch this issue a little bit more...

Andi
Comment 9 caulier.gilles 2019-12-28 06:22:43 UTC
Not reproducible with 7.0.0-beta1