Also, this seems to be against some old version of
WinMerge? (2.2.x?) CListViewEx was removed a while ago
from sources since it wasn't really needed. Please provide
patches against latest version since there are a lots of
changes done after 2.2 releases. Best would be to add original
and altered file to archive file so we could use WinMerge to
handle the patch :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got this e-mail from the same guy. I'm not sure it provides
more insight though.
Hi, Christian
We use winmerge at my work and people like it.
Couple guys wanted to see colors in the file difference
window so I made a small patch to enable it and also
to remove flicker from the same window.
May be you will find it usefull
Regards,
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't like hardcoded colors (we can now even customize
syntax highlight colors!). Maybe we could use file compare
colors?
Also, lots of people don't need this coloring (I'm amongs
them, I've once implemented this also but I think I never
submitted that patch) so we'll need menuitem for
enable/disable this coloring.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This patch is against the latest version of winmerge 2.2.4.
Files modified for colors for different statuses: dirview.h
dirview.cpp listvwex.h listvwex.cpp
For removing flicker files modified: dirframe.h dirframe.cpp
CListViewEx is still used it's not removed in latest version
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I ported this to cvs trunk. I moved the notify to DirView --
I don't know how it worked in 2.2, but current DirView does
not inherit from anything in listvwex, so it couldn't be
done in listvwex (and I had no desire to make it so).
It surely is visually striking. As Kimmo says, colors should
be configurable.
Attaching patch (against cvs trunk).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At least that flicker remove part should be applied to CVS
trunk (and later to 2.4 branch). At least in CVS trunk I now
see some flicker when I have short sizes visible.
For dirview colors we need new options dialog to configure
them, like for file compare colors.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've attached patches Matthias sent me (avoidflicker.patch and difffoldercolor.patch).
I'm not sure we need the flickering patch anymore. But it looks innocent and if it helps somebody...
I don't like the coloring patch. I'm afraid it only has negative effects. Does it slow down updates with like 10000 items visible with different colors? Lots of new configuration. Finding good color combinations (just for default colors) is very hard. What is the real value of the colors? Other than some people have used to them in other tools.
I've said in many other items and discussions that I think using colors for compare status is waste of time and waste of GUI resources. We really have better uses for colors in folder compare. We have already enough GUI for the compare status, icons filters, couple of columns etc. Lets use colors for something more creative.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
shit
>Lower priority until somebody implements the GUI. Hardcoded
>colors WON'T go into CVS.
just the opposit of your last comment.
Means I wasted my time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That comment only meant "I won't even consider this before...". It was not a promise to include the feature. And that comment was 3 years old, lots of things have changed since then. Don't trust anything years old.
Since then this has been discussed in several forum threads and other items. Where I've said I don't like this idea anymore. I can't update every single item after every discussion.
It is important to ask/discuss before submitting big GUI patches.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, As I am also a user with realy bad eyes, I prefer coloring to indicate the result istead to read text or to check the small icons, what is mostly not also easy.
Time lost will not be there, as to view the results also while scrolling through, takes longer as the painting (0,001%), that time we can ignore.
But it's your decision.
If don't like it anymore, close the item.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's been 3 more years now, and I'm starting to think that I like the idea of coloring the background to indicate the comparison status.
It does give the user easier feedback.
Especially in a large set of files it is much easier to spot the file you are looking for.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't avoid the impression that you just haven't had many occasions to compare folders. I'm doing it when a client gave me a ZIP file with his changes instead of checking them in to SVN -- a use case crying out for a different solution, admittedly. But here I am, and here I turned to WinMerge for rescue. But the folder-compare window seems almost malevolently designed to make it hard to distinguish identical files from different files.
the phrases in the Comparison-result column are remarkably indistinguishable visually: "Text files are identical" and "Text files are different".
the Differences column is no better, "0" does not stand out as different from any other digit.
The intransigence against colors or icons or norms with other software does nothing to dispel this impression. All those arguments could be applied to colorizing differences within files, which are so clearly useful.
Suggestions:
Comparison-result column: make it blank for text files that are identical.
Differences column: make it blank when there are 0 differences.
Use similar colors for intra-file differences as inter-file differences.
That last suggestion is woefully un-thought-through. I'm sure lots of comparisons between lines of text don't translate easily to files. But it's a start.
Last edit: Bob Stein 2019-03-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
patch for colors in diff file window
Logged In: YES
user_id=631874
First, there are no filenames in patch - hard to guess which
files you are modifying.
Second, Unified or Context diff with some lines of context
would be a lot easier to look at.
Third, care to tell exactly what the patch does? Hard-coded
colors for different statuses in folder compare?
Logged In: YES
user_id=631874
Also, this seems to be against some old version of
WinMerge? (2.2.x?) CListViewEx was removed a while ago
from sources since it wasn't really needed. Please provide
patches against latest version since there are a lots of
changes done after 2.2 releases. Best would be to add original
and altered file to archive file so we could use WinMerge to
handle the patch :)
Logged In: YES
user_id=609728
I got this e-mail from the same guy. I'm not sure it provides
more insight though.
Hi, Christian
We use winmerge at my work and people like it.
Couple guys wanted to see colors in the file difference
window so I made a small patch to enable it and also
to remove flicker from the same window.
May be you will find it usefull
Regards,
Alex
Logged In: YES
user_id=631874
I don't like hardcoded colors (we can now even customize
syntax highlight colors!). Maybe we could use file compare
colors?
Also, lots of people don't need this coloring (I'm amongs
them, I've once implemented this also but I think I never
submitted that patch) so we'll need menuitem for
enable/disable this coloring.
Logged In: NO
This patch is against the latest version of winmerge 2.2.4.
Files modified for colors for different statuses: dirview.h
dirview.cpp listvwex.h listvwex.cpp
For removing flicker files modified: dirframe.h dirframe.cpp
CListViewEx is still used it's not removed in latest version
Logged In: YES
user_id=1195173
I'll confirm nobody's comment below, that listview is in the
latest, grepping against cvs trunk:
Src\Common\listvwex.cpp(1):// ListVwEx.cpp : implementation
of the CListViewEx class
Zip (52Kb) of 4 altered & original files (DirFrame & DirView)
Logged In: YES
user_id=1195173
I ported this to cvs trunk. I moved the notify to DirView --
I don't know how it worked in 2.2, but current DirView does
not inherit from anything in listvwex, so it couldn't be
done in listvwex (and I had no desire to make it so).
It surely is visually striking. As Kimmo says, colors should
be configurable.
Attaching patch (against cvs trunk).
Jpeg screenshot (84Kb)
Logged In: YES
user_id=1195173
Also attaching demo screenshot.
Logged In: YES
user_id=631874
At least that flicker remove part should be applied to CVS
trunk (and later to 2.4 branch). At least in CVS trunk I now
see some flicker when I have short sizes visible.
For dirview colors we need new options dialog to configure
them, like for file compare colors.
Logged In: YES
user_id=631874
Lower priority until somebody implements the GUI. Hardcoded
colors WON'T go into CVS.
after about 3 years, I finshed that job.
I will post the patch to Kimmov, as the rule doesn't allow it to add files for me.
The avoid flicker patch against current SVN trunk
Folder compare coloring patch against current SVN trunk
I've attached patches Matthias sent me (avoidflicker.patch and difffoldercolor.patch).
I'm not sure we need the flickering patch anymore. But it looks innocent and if it helps somebody...
I don't like the coloring patch. I'm afraid it only has negative effects. Does it slow down updates with like 10000 items visible with different colors? Lots of new configuration. Finding good color combinations (just for default colors) is very hard. What is the real value of the colors? Other than some people have used to them in other tools.
I've said in many other items and discussions that I think using colors for compare status is waste of time and waste of GUI resources. We really have better uses for colors in folder compare. We have already enough GUI for the compare status, icons filters, couple of columns etc. Lets use colors for something more creative.
shit
>Lower priority until somebody implements the GUI. Hardcoded
>colors WON'T go into CVS.
just the opposit of your last comment.
Means I wasted my time.
That comment only meant "I won't even consider this before...". It was not a promise to include the feature. And that comment was 3 years old, lots of things have changed since then. Don't trust anything years old.
Since then this has been discussed in several forum threads and other items. Where I've said I don't like this idea anymore. I can't update every single item after every discussion.
It is important to ask/discuss before submitting big GUI patches.
Hmm, As I am also a user with realy bad eyes, I prefer coloring to indicate the result istead to read text or to check the small icons, what is mostly not also easy.
Time lost will not be there, as to view the results also while scrolling through, takes longer as the painting (0,001%), that time we can ignore.
But it's your decision.
If don't like it anymore, close the item.
It's been 3 more years now, and I'm starting to think that I like the idea of coloring the background to indicate the comparison status.
It does give the user easier feedback.
Especially in a large set of files it is much easier to spot the file you are looking for.
I can't avoid the impression that you just haven't had many occasions to compare folders. I'm doing it when a client gave me a ZIP file with his changes instead of checking them in to SVN -- a use case crying out for a different solution, admittedly. But here I am, and here I turned to WinMerge for rescue. But the folder-compare window seems almost malevolently designed to make it hard to distinguish identical files from different files.
The intransigence against colors or icons or norms with other software does nothing to dispel this impression. All those arguments could be applied to colorizing differences within files, which are so clearly useful.
Suggestions:
That last suggestion is woefully un-thought-through. I'm sure lots of comparisons between lines of text don't translate easily to files. But it's a start.
Last edit: Bob Stein 2019-03-24