Page 2 of 2
Posted: Tue Dec 12, 2006 7:55 pm
by helmut
Olivier_G wrote:=> I don't see any bug and I believe this thread should be closed, Right?
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.
Posted: Tue Dec 12, 2006 7:58 pm
by xnview
helmut wrote:Olivier_G wrote:=> I don't see any bug and I believe this thread should be closed, Right?
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.
Yes, it seems, but can't reproduce it
Re: not in path
Posted: Tue Dec 12, 2006 8:33 pm
by Olivier_G
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:
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...
So, I don't get it...
Re: not in path
Posted: Tue Dec 12, 2006 9:14 pm
by helmut
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)
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".
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?
Posted: Wed Dec 13, 2006 3:13 pm
by Olivier_G
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')
Posted: Wed Dec 13, 2006 5:43 pm
by xnview
Olivier_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')
yes
Posted: Wed Dec 13, 2006 6:10 pm
by foxyshadis
Is it possible to make it a multiline label, instead of a scrollable label? Hmm, but that'd require laying it out anew, which you might want to keep until you redo the dialog later on. Oh well. *shrug*
Posted: Wed Dec 13, 2006 11:35 pm
by helmut
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