No, there is a bug. Look at the path of the left and right image in the screenshot above. The paths are both the same - which is wrong.Olivier_G wrote:=> I don't see any bug and I believe this thread should be closed, Right?
Find similar lists same file twice.
Moderators: helmut, XnTriq, xnview
Re: not in path
But this image doesn't show the full paths ("r" from "bilder" is exactly the limit of what is showned here. You'd better show the end, IMO):

Therefore one can be a duplicate of the other in a subfolder, which is what you said here:

Therefore one can be a duplicate of the other in a subfolder, which is what you said here:
So, I don't get it...helmut wrote:Yes, the same file is listed in a subfolder named "500 images". I've just renamed the file in the subfolder, then the problem no longer occurs. You are on the right track...

Olivier
Re: not in path
OMG, you are right! The truncated path name was the problem: The path happened to be truncated so that it didn't look as it if it was truncated. Shortening the parent folder name revealed the subfolder and even revealed another problem "Two backslashes in path name".Olivier_G wrote:But this image doesn't show the full paths ("r" from "bilder" is exactly the limit of what is showned here. You'd better show the end, IMO)
The problem is that the path name is just truncated without showing any elipsis or any other hint. Pierre, could you do something about this?
Beta 5 shows the end of the path by default instead of the beginning. I think it's better to avoid that subfolders issue found here.
There is still no "..." when the text is truncated (beginning or end), but it doesn't seem possible in a field where you can select/move the content (I tried with Windows XP Properties and Opera => same thing).
Do you confirm this, Pierre? (if so, I'll move it to 'closed')
There is still no "..." when the text is truncated (beginning or end), but it doesn't seem possible in a field where you can select/move the content (I tried with Windows XP Properties and Opera => same thing).
Do you confirm this, Pierre? (if so, I'll move it to 'closed')
Olivier
yesOlivier_G wrote:Beta 5 shows the end of the path by default instead of the beginning. I think it's better to avoid that subfolders issue found here.
There is still no "..." when the text is truncated (beginning or end), but it doesn't seem possible in a field where you can select/move the content (I tried with Windows XP Properties and Opera => same thing).
Do you confirm this, Pierre? (if so, I'll move it to 'closed')
Pierre.
- foxyshadis
- Posts: 395
- Joined: Sat Nov 18, 2006 8:57 am
In Beta 5 one can well see that it's different paths. 
The only issue left is how to display the truncated path names best - you have raised this, already. Really hard to say what to do, here.
When thinking about ideas something else (a bit offtopic) came to my mind:
- Window title with search base
Currently the window title of the dialog with search results says "Compare image", which is pretty wrong. I'd suggest something like "Similar files found in <base folder>"", where base folder is the folder the search has been started in.
Perhaps the path names could ommit the search base, that is if search has been started in C:\Temp\Samples\ and a similar file has been found in C:\Temp\Samples\Animals\Mammals\, the path shown could be .\Animals\Mammals\. But it would be a bit odd if you started your search in D:\ and it would just ommit the drive letter.
The most effective solution would be making the area for the path larger. Currently it is a bit small. I don't like the multiline approach, though. Hmm, but multiline might actually solve the problem. Hmm.
-> Feedback & Info

The only issue left is how to display the truncated path names best - you have raised this, already. Really hard to say what to do, here.
When thinking about ideas something else (a bit offtopic) came to my mind:
- Window title with search base
Currently the window title of the dialog with search results says "Compare image", which is pretty wrong. I'd suggest something like "Similar files found in <base folder>"", where base folder is the folder the search has been started in.
Perhaps the path names could ommit the search base, that is if search has been started in C:\Temp\Samples\ and a similar file has been found in C:\Temp\Samples\Animals\Mammals\, the path shown could be .\Animals\Mammals\. But it would be a bit odd if you started your search in D:\ and it would just ommit the drive letter.
The most effective solution would be making the area for the path larger. Currently it is a bit small. I don't like the multiline approach, though. Hmm, but multiline might actually solve the problem. Hmm.
-> Feedback & Info