https://bugs.kde.org/show_bug.cgi?id=372781
--- Comment #2 from Mario Frank <mario.fr...@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 watching all bug changes.
