Actually this has been a TODO comment for a long time. I
thought about adding description given for folders to files
opened from folder compare. But there are cases you don't
want/need it.
What use it is for user if descriptions are "WinMerge 2.4.0"
and "WinMerge 2.6.0". They make sense for folders compared,
but once you open some file, they are not filenames...
So I think we'd need to append original filename if it is
not present in description. Something like "WinMerge 2.6.0 :
DirDoc.cpp"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
They aren't directory names or filenames, so, to me, they
have the same value on both directory pages and on file
(editor) pages.
In fact, this patch prepends them to the existing filepaths.
Granted, the existing filepaths are terrible, and nearly
worthless unless you have huge monitor or very small
directory tree, because it doesn't show the part of the path
differing between left and right, so I don't care if that
gets lost, but I figured some people might have small
directory tree and could still benefit from them, so I left
them in -- I just prepended the labels the user requested
(via /dr and /dl -- at least, that is how I set them, I
don't know if there is a way in the GUI).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How does it help situation if you just append the
description to filepaths? In most situations they just don't
fit and only make the display more messy looking. We are not
coding for some special cases.
What we need is somebody to figure out algorithm for showing
those two almost identical paths sanely.
So that we can only show meaningful parts of the paths in
both panels.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't append them, I prepended them, so they're visible
-- then the paths can do whatever afterwards -- they were
broken and I left them as they were.
But I implemented this in my version, so you can close this
if you like.
(And maybe later when you do a full fix for paths, I'll copy
the whole fix -- I'll certainly be happy to get a fix at
whatever time.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
7-Zip file (30Kb) of 3 altered & original files
Logged In: YES
user_id=631874
Actually this has been a TODO comment for a long time. I
thought about adding description given for folders to files
opened from folder compare. But there are cases you don't
want/need it.
What use it is for user if descriptions are "WinMerge 2.4.0"
and "WinMerge 2.6.0". They make sense for folders compared,
but once you open some file, they are not filenames...
So I think we'd need to append original filename if it is
not present in description. Something like "WinMerge 2.6.0 :
DirDoc.cpp"
Logged In: YES
user_id=1195173
They aren't directory names or filenames, so, to me, they
have the same value on both directory pages and on file
(editor) pages.
In fact, this patch prepends them to the existing filepaths.
Granted, the existing filepaths are terrible, and nearly
worthless unless you have huge monitor or very small
directory tree, because it doesn't show the part of the path
differing between left and right, so I don't care if that
gets lost, but I figured some people might have small
directory tree and could still benefit from them, so I left
them in -- I just prepended the labels the user requested
(via /dr and /dl -- at least, that is how I set them, I
don't know if there is a way in the GUI).
Logged In: YES
user_id=631874
How does it help situation if you just append the
description to filepaths? In most situations they just don't
fit and only make the display more messy looking. We are not
coding for some special cases.
What we need is somebody to figure out algorithm for showing
those two almost identical paths sanely.
So that we can only show meaningful parts of the paths in
both panels.
Logged In: YES
user_id=1195173
I didn't append them, I prepended them, so they're visible
-- then the paths can do whatever afterwards -- they were
broken and I left them as they were.
But I implemented this in my version, so you can close this
if you like.
(And maybe later when you do a full fix for paths, I'll copy
the whole fix -- I'll certainly be happy to get a fix at
whatever time.)
Logged In: YES
user_id=631874
I'm not doing full fix anytime soon. And I don't consider
hacks for GUI now.
As I've stated numerous times I'm not going to work with GUI
for some time, unless it is a bug really needing a fix (for
stable release).