BestImageViewer
Find Duplicates: toolbar button returns no results when right-click does
ISSUE TYPE
- Bug Report
GEEQIE VERSION
Geeqie 2.1 GTK3
OS / DISTRIBUTION
Xubuntu 23.04
SUMMARY & STEPS TO REPRODUCE
In Folder View, right click, Find Duplicates and Find Duplicates Recursive both find existing duplicates based on similarity (this general issue may also pertain to other dupe types). The Find Duplicates button does not find anything, even if I'm sure to single-left-click the folder first, to ensure it's focused as the input for the Find Dupes.
Relatedly, please can you LMK the expected behaviour of Find Dupes as pertains to remembering the settings? I only use High Similarity; often when I hit Find Dupes either within the same Geeqie instance or a new one, it defaults to searching on Name. Yet other times it'll remember my previous setting. It would be nice if this was remembered across Find Dupes requests / sessions. Not sure if this is a feature request or a bug - LMK if you'd like me to make this a separate issue.
Cheers!
The Find Duplicates button does not find anything, even if I'm sure to single-left-click the folder first, to ensure it's focused as the input for the Find Dupes.
When you right-click in the folder pane, a dupes search is started in the folder that you have clicked on (which will not be the one being displayed in the files pane).
If you have a Dupes icon on the toolbar, the action is the same as using File/Find Duplicates - which opens a blank dupes window so that you can drag-and-drop folders onto it.
Having drag-drop as the only way to set up the dupes window has never seemed quite right to me. Maybe a bit of a redesign is necessary.
The settings should be remembered. This will show you the state after Geeqie is closed:
grep duplicates_ $HOME/.config/geeqie/geeqierc.xml
Where:
duplicates_select_type
DUPE_SELECT_NONE, = 0
DUPE_SELECT_GROUP1,
DUPE_SELECT_GROUP2
duplicates_match
DUPE_MATCH_NONE = 0,
DUPE_MATCH_NAME = 1 << 0,
DUPE_MATCH_SIZE = 1 << 1,
DUPE_MATCH_DATE = 1 << 2,
DUPE_MATCH_DIM = 1 << 3, /**< image dimensions */
DUPE_MATCH_SUM = 1 << 4, /**< MD5sum */
DUPE_MATCH_PATH = 1 << 5,
DUPE_MATCH_SIM_HIGH = 1 << 6, /**< similarity */
DUPE_MATCH_SIM_MED = 1 << 7,
DUPE_MATCH_SIM_LOW = 1 << 8,
DUPE_MATCH_SIM_CUSTOM = 1 << 9,
DUPE_MATCH_NAME_CI = 1 << 10, /**< same as name, but case insensitive */
DUPE_MATCH_NAME_CONTENT = 1 << 11, /**< same name, but different content */
DUPE_MATCH_NAME_CI_CONTENT = 1 << 12, /**< same name - case insensitive, but different content */
DUPE_MATCH_ALL = 1 << 13 /**< N.B. this is used as a clamp value in rcfile.cc */
Cheers as always for the replies mate.
which will not be the one being displayed in the files pane
Necessarily not? I must be misunderstanding... If I leftclick a folder in the folder tree, that folder's files are displayed in the files pane, the first (image) file displayed in the image pane, and hence I assumed the selected folder's contents would be populated as the input into a Find Dupes mainmenu or keyboard shortcut call. But evidently not:
opens a blank dupes window so that you can drag-and-drop folders onto it
Maybe a bit of a redesign is necessary
Certainly if there's a way to populate the call to open Find Dupes with the selected folder... but then if a user WANTS a blank Find Dupes to drag specific files into....? IDK how common this would be though? User can always select all & hit delete to remove I guess...
geeqierc.xml settings are:
duplicates_similarity_threshold = "99"
duplicates_match = "0"
duplicates_select_type = "1"
duplicates_thumbnails = "true"
Existing instance, having already tried rightclick folder, FDR: high similarity (95 not 99 fwiw) selected, i.e. last choice, i.e. good. As above, different folder: same. Good. New instance: rightclick folder, FDR: high similarity (95 not 99 fwiw) selected, i.e. last choice, i.e. good.
Second instance (related to my old issue where, all of a sudden, I was able to have multiple instances of Geeqie, which I never was able to remedy): rightclick folder, FDR: high similarity (95 not 99 fwiw) selected, i.e. last choice, i.e. good. Kinda surprised by this as I was thinking maybe the new instance opens with factory default config which overwrites any instance-1 changes, but seemingly not for F.D. Each extra instance does open with Folder View off though, and potentially other settings changed.
Frustratingly typical bugfixing, can't replicate the issue when I want to, happens all the time when I don't want! I wonder if FD(R) settings are affected by user actions... my usual process is
- sort by size
- select first group (keyboard 1)
- delete those files (keyboard shift-delete (which wasn't working yesterday, it was just removing the files. This may have been happening for AGES, and I've just been assuming they were deleted, not thinking to re-run FDR. I'll investigate & open a new issue if so)).
I struggle to think why any of this would change settings though.
Ooh ok something has changed them, I just refocused on the settings and got a prompt saying they'd changed, now I have:
duplicates_match = "64"
Which I presume is Name? Changed to Similarity high, closed Geeqie, config prompted to refresh but duplicates_match = "64" remains. Reopened Geeqie, FDR is similarity 95 still. Close Geeqie, config prompted to refresh but duplicates_match = "64" remains. I can now loop this: open Geeqie, FDR, is Similarity High, do nothing, close Geeqie, config prompt, nothing seems to have changed, certainly nothing in the FD section.
Stumped!
Edit: related to shift+delete (delete files) actually behaving like delete (remove from list), which I just confirmed and am opening an issue for, having just done this, the FD settings were reset to Name. So this might be it! Investigating further. I changed custom similarity from 99 to 96 in the previous instance, closed Geeqie, and that setting seems to have been retained, just not the choice of filter (Similarity vs Name).
Ok: found a folder with dupes. Open fresh instance, FDR, select similarity high, do nothing, close FDR, close Geeqie. Open fresh instance, FDR, Similarity high present, therefore doing nothing & quitting does change the settings. Now sort by size, select 1st group, shift+delete keys, files removed from list but not deleted (bug, will post to that report). Close FDR. Close Geeqie. Open Geeqie. FDR. FUCK YEAH: filter defaulted to Name, so this is the reproducible workflow. Bloody hell that was a tricky one! Finally: open Geeqie, FDR, defaults to last setting since I didn't do anything i.e. Similarity High, size, group1, rightclick, delete. Files deleted. Close geeqie, reopen geeqie, FDR: defaults to name.
SO: the Delete function (shift+delete key) resets the FD(R) type setting to Name. Independently, the keyboard shortcut Removes, instead of Deleting.
Goodness what an ordeal! Now for some breakfast and day job. Accidentally productive morning on the wrong thing! haha
Necessarily not? I must be misunderstanding
Another brain-fade moment. I only use the folder pane set to View As List.
I still find no problem with settings not being retained.
The values for :
duplicates_match
DUPE_MATCH_NONE = 0
DUPE_MATCH_NAME = 1
DUPE_MATCH_SIZE = 2
DUPE_MATCH_DATE = 4
DUPE_MATCH_DIM = 8
DUPE_MATCH_SUM = 16
DUPE_MATCH_PATH = 32
DUPE_MATCH_SIM_HIGH = 64
DUPE_MATCH_SIM_MED = 128
DUPE_MATCH_SIM_LOW = 256
DUPE_MATCH_SIM_CUSTOM = 512
DUPE_MATCH_NAME_CI = 1024
DUPE_MATCH_NAME_CONTENT = 2048
DUPE_MATCH_NAME_CI_CONTENT = 4096
DUPE_MATCH_ALL = 8192
I might make a change to the duplicates user interface as follows:
In the duplicates window in both main and secondary panes include a right-click menu item labelled "Include File or Folder".
This brings up a file/folder select sub-window as is used elsewhere. There will be a check box labeled "Recurse" (which will only be meaningful if a folder is selected).
The state of the check box will be remembered from the last time.
The menu item File/Find Duplicates will open the dupes window with the Select Folder sub-window already open and set to the current folder. The user can either press return to accept or escape to start with a blank window or navigate elsewhere.
A Find Duplicates item on the toolbar will have the same method.
Sorry for the delay in responding.
The user can either press return to accept or escape to start with a blank window or navigate elsewhere.
I think this is a nice approach.
I still find no problem with settings not being retained.
Alas. I've updated to github latest which has fixed the Shift+Delete issue (woo!) but not the settings being lost issue, which is caused by actioning the F.D. deletions.
I wonder if this is related to my 'multiple instances allowed' issue from ages ago? Plausibly the fact that I can spawn multiple instances, which typically have 'default' settings for tree view (i.e., no tree view) and other things (pane sizes etc.) might mean that they cause settings override?
But arguably not because in the current version (2.1+git20230822-ee5b7a48) I can spawn one instance (lw1), FDR: set settings, NOT delete, close, reopen, FDR: settings are retained, DO delete, close, reopen, FDR: settings are lost. This is all spawn/respawning lw1.
With FD settings set to Similarity high:
grep dup geeqierc.xml
duplicates_similarity_threshold = "96"
duplicates_match = "0"
duplicates_select_type = "1"
duplicates_thumbnails = "true"
collections_duplicates = "false"
threads.duplicates = "-1"
dupe_window.x = "647"
dupe_window.y = "1279"
dupe_window.w = "1278"
dupe_window.h = "1053"
FDR: delete, close window, close Geeqie, already-open-in-mousepad geeqierc.xml prompts file change dialog,
grep dup geeqierc.xml
duplicates_similarity_threshold = "96"
duplicates_match = "64"
duplicates_select_type = "1"
duplicates_thumbnails = "true"
collections_duplicates = "false"
threads.duplicates = "-1"
dupe_window.x = "2125"
dupe_window.y = "1351"
dupe_window.w = "1278"
dupe_window.h = "1053"
So deleting dupes is definitely causing the settings to be changed/reset, which is written to the xml on geeqie close.