[digikam] [Bug 372781] The recent similarity range is not saved which may lead to odd results.

[Mario Frank]

https://bugs.kde.org/show_bug.cgi?id=372781

--- Comment #2 from Mario Frank <mario.frank at uni-potsdam.de> ---
(In reply to caulier.gilles from comment #1)
> If i'm not too wrong, the similarity threshold must be saved in SAlbum in
> database, as property. We need to do the same for max threshold typically...
> 
> Gilles Caulier

Hey Gilles,
this is done in fuzzy search where only one SAlbum is done. In fact, for fuzzy
search, the recently used minimum and maximum values are also stored in the
digikamrc.

In duplicate search, saving the range in every search query can bloat the
database size unnecessarily. Moreover, it would be necessary to ensure that for
all duplicates searches, the range is equal. This is a fact currently.

I think there is a better solution. The FuzzySearchView is a StateSavingObject.
This ensures that on startup, the last values are loaded and on shutdown, the
current are saved. But this is not sufficient in this context since the range
used in the maintenance dialog should be automatically synced in the
FindDuplicatesView. Here, I do not think that using StateSavingObject is
sufficient. For recently used tags, the coredb automatically synchronises after
every tag change, for example.

I see two spots where one could set a hook. Independently from where you
trigger duplicate search, you always will eventually call slotDone or
slotCancel in DuplicatesFinder. I think slotDone is the best spot to save the
least recently used range.

The next spot is the FindDuplicatesView. In the constructor, the least recent
range can be loaded instead of default values.

But if you use the maintenance dialog after the FindDuplicatesView is
instantiated, this would not help since the values are already set. Luckily,
the finished search finally leads to a call of the slots albumDeleted,
albumAdded or searchUpdated since they are connected to the AlbumManager.
In these slots, the range could be updated to the least recent range.

I do not think that accessing the digikamrc from different classes
(DublicatesFinder, FindDuplicatesView and MaintenanceMgr) is a really good
solution since it leads to much code. I thought about using the Settings table
of the database since the access is straightforward.

In fact, I also have a patch here... Just take a look

-- 
You are receiving this mail because:
You are the assignee for the bug.