RFE: Find Duplicates - Highlight Alternating Dups

[therube]

RFE: Find Duplicates - Highlight Alternating Dups

Oh perhaps an option to highlight alternating sets of dups.
Something like, https://images.pcworld.com/images/artic ... 139070.jpg.

[void]

Thanks for the suggestion therube,

I will consider alternating the row color of different property values when searching for duplicated items.

[therube]

As it is, I (most) often have various columns "out of focus".
Like say; Length.

I not really concerned about Length except for when I'm looking for duplicates.
So being out of focus allows for lazy load of that data. (I don't index Length.)

And when I want to Find Length Duplicates, so I bring that column into focus & perform a 'Find Length Duplicates'.
At that point, once again, Length (itself) is kind of immaterial,
but knowing which sets of files are of equal Length, is.

So (again) with Length column out of focus,
if there were highlighting giving visual reference to said duplicates, I can see dups without having to look (specifically) at Lengths (& without going to lengths to do so .)

[therube]

(Just some commentary, rambling...)

• Everything Group - AllDup.jpg
  (default) sort by file size / group
  it's a duplicate file finder, so (generally) can't deal with random file locations, only directory trees

• Everything Group - batch file.png
  very simply, very quick, i select files from within Everything, & (Windows) SendTo
  in this case, i generally know what & why i'm hashing (generally as a random check
  to check for failing drives, & further to confirm exactness between particular files)
  - for some reason, output like this is easy for me to scan down through & pick out
  *mismatches* - as in i can go down & see: dup dup dup dup dup WRONG dup dup dup dup
  - a lot of times it's that WRONG that i'm concerned about (or rather that it doesn't occur)
  (in the screenshot below, they are just random files, even though there are dups
  so this particular listing is worthless - for my usage)

• Everything Group - CHK Hash Tool.png (chk.exe)
  can accept random files from random locations...
  does highlight groups
  default sort order is the order files are sent to chk (drag & drop, command line, or Open directory...)
  1. sort - name, 2. sort - hash (Ctrl+d)
  - problem with 1. is because of name sort, while it does highlight dups, there is no congruity, so it's
  basically says, hey, yeah, you do have dups in there
  - problem with 2., sorted by hash, is that it emboldens (yellow) the 1st item in each dup group, & if in
  your mind you can think; yellow+gray(s) is 1 group, followed by yellow+gray(s) is the next group...,
  well, i can't. if it were simply two sets of colors; a band of yellows, a band of grays, followed by
  another band of yellows... then you can say, ah, that "group" of yellows are dups, & /that/ group of
  grays are dups...

• Everything Group - Duplicate Cleaner.jpg
  (default) grouped by "Group" (not quite sure just what that means)
  it's a duplicate file finder, so (generally) can't deal with random file locations, only directory trees

• Everything Group - Everything.jpg
  1. sort - name
  2. sort - size
  3. sort - length
  when looking for dups here, i might sort by Length, & at the same time, i'll typically have Length out
  of view (like shot #1), so i can't "see" Length duplicates & even if i did have Length column in focus,
  "manually" looking at sets of numbers to "find" dups is not easy (for me); 1.55 1.55 3.53 3.53 3.53 3.53 3.57 3.57 ... 7.57 7.57 ...
  - it's at this point where Everything could help
  (again with a view like shot #1), if equal Lengths (or size, or...) were "Grouped" (highlighted)
  together, i could "see" duplicated Lengths without actually /seeing/ the Length column (as at this
  point in time, the physical length is immaterial, only the fact that there are some the same [dups])

• Everything Group - HashMyFiles.jpg
  can accept random files from random locations (iow, potentially can very well complement Everything)
  can highlight goups
  1. sort - name, 2. sort - hash
  - that said, HMF has always been quirky with drag&drop, it's coloring (to my partially color blind eyes)
  is all but for not, i cannot really distinguish between the subtle (to me) colors, so with that its
  "grouping" is ineffectual & to know that i'm really looking at dups, i've got to look at the hash &
  at that point, my simply batch file is very effective (for me)
  - if he limited to 2 alternating colors, to me, that would easily point out "groups" & make the
  program much better

THEN

on top of dups & grouping them & visually highlighting (or otherwise distinguishing) "groups", you also will
have the "non-groups". i.e., if you are always dealing only with groups of some sort; Size Dup or Name Dup or
Date Modified Dup... then you only need two colors to account for all grouping possibilities

BUT

everything also deals with non-groups, files that are not Size Dup or Name Dup or... so those also need to be
"grouped" (or not-grouped as the case would be), so then you need at least 3 sets of colors;
say yellow & blue & white, where yellow & blue could be alternating group colors & white being non-group files
(which could be confusing if you wanted white to be one of your "group" colors)

& then, you'd have to see how things play out - in reality...


note: 297_4-5_CONCATxxxxxxx.flv in particular, & where it turns up in various programs & with various sorting

- in chk.#1 they are in white, not quite sure why, as there are 2 dups in that white band?
- in chk.#2, heh, you have to physically look for the dups, eh Charlie Brown, well you can (clearly, heh)
see 1 set of groups of it, yellow+gray [remember], but then that 3rd instance of that file name, white
in #1 is actually a group with a different named file, "297_4_CONCAT.flv" (again, yellow+gray) at the
very bottom of the listing

- the actual duplicate file finder programs don't have this problem as they only deal with dups & they do
group by "groups"
- Everything, currently , /you/ have to physically /look/ to find "groups" - even if they are grouped
together
- HashMyFiles, sorted by name, basically has the same issue as chk.#1, but his "297" group (of 3) end up
in differing shades of "blue" (they might as well be one to me). hmf#2 is like chk.#2, only it's not
readable (to me)
- batch file, works very well (for me) - assuming files are sent to it in the expected order, as i can
easily go do the list & easily (generally only dealing with the last 3 characters) spot mismatches

NOW...

in Everything, if i'm sorted by Name, & i can hit a "highlight" hotkey, & it iterates through the names highlighting
dup'd names; yellow yellow white white white blue blue blue blue yellow yellow yellow white blue blue white...
something like that might work?

if i'm sorted by Length [or Size or...] (& in my case Length [or Size...] is typically not in view), & i hit that
hotkey & it does the same, again noting all my Length [Size...] dups, then i can "see" duplicates without /seeing/
them & that would be great

---
.
.
AllDup:

Everything Group - AllDup.png (219.27 KiB) Viewed 43926 times

Batch file:

Everything Group - batch file.png (14.47 KiB) Viewed 43926 times

CHK:

Everything Group - Chk.png (47.64 KiB) Viewed 43926 times

Duplicate Cleaner:

Everything Group - Duplicate Cleaner.png (295.4 KiB) Viewed 43926 times

Everything:

Everything Group - Everything.png (340.21 KiB) Viewed 43926 times

HashMyFiles:

Everything Group - HashMyFiles.png (340.73 KiB) Viewed 43926 times

[raccoon]

Some time I had suggested that Everything might add Checkbox Select, especially for older people who aren't as nimble with the mouse and Shift+Click and Ctrl+Click.

I think adding Checkbox Select could also open the door for some new select activities, such as allowing selected object to persist in their selection between changes in the search filter, so as to better refine one's selection. Also an added verb selected: to only show selected objects.

This way the user has the ability to really tinker with their selected files before committing to an action, given there are a lot of different criteria for what might be considered a duplicate or wanted/unwanted file.

In the absence of a Checkbox Select, I've been using Advanced Rename to tag objects with a magic word in their name, so that I can later search for all objects with that magic word before making my final delete, move, w/e. (Search: %1, Replace: %1 [deleteme])

[void]

Thanks for the suggestions therube,

Some of these are tricky to do as Everything results are live.
I have put on my TODO list to color the results based on the XOR data from the current sort.
I'll have to trial this as the same color might end up being used next to each other.

Another option might be to use a dividing line between groups.


Thanks for the checkbox suggestion raccoon,
I will consider an option to do this.
I do have on my TODO list to add a work area sidebar where you can drag drop files to and from.
It might be useful for marking files.
File list slots might also be a option.

[void]

Everything 1.5.0.1286a adds an experimental group_colors ini setting to show groups of results with the same property value for the current sort in different colors.

To enable group colors:

• In Everything, type in the following search and press ENTER:
  /group_colors=1
• If successful, group_colors=1 is shown in the statusbar for a few seconds.

Everything will use a XOR hash of the property value to calculate the color.
Unfortunately, different values near each other can sometimes use the same color.

Please let me know if the colors are too saturated and need to be dimmed.

[raccoon]

Wow. /group_colors=1 is really trippy. I'm going to commit to driving this for a week.

I can almost taste the rainbow.

[therube]

For me, I'm thinking more of an on demand kind of thing, so a hotkey to toggle highlight on or off.
(I would not want it on, all the time. Though I might want it on - for an extended period of time - depending on what I happen to be doing, & whether highlighting is relevant to that.)

And colors, yes, rainbow.
I'd much rather have sets of colors, contrasted against white (for non-duplicates).
Presumably, with that, you'd have a far lessor set of colors, perhaps only two (plus white).

1. Name, 2. Path, 3. Size, 4. Date
1 a mess, 2 better - because there is some commonality there, 3 pretty much a mess, 4 ditto

Everything highlight DUP'd Properties 1.png (177.6 KiB) Viewed 43452 times

.
.
1. Name, 2. Path, 3. Size, 4. Date
if only the actual dup'd items were highlighted, & all else were white (you have to use your imagination for that part ), then you would have easily recognizable, sets of dups, against an otherwise all white listing (of everything else).
(In 2., note how the [two different] pinks "merge" [to my eyes].)

Everything highlight DUP'd Properties 2.png (48.29 KiB) Viewed 43452 times

(right-click, View, to see larger image...)


And, all that said, what is there, now, is likely to be benefit as is, though I've got to put it through the wringer & see how it pans out in actuality.


(Only a very quick look so far, but there is a quirk in there, maybe DUPE didn't show up a time or two or something - even though results were filtered... ?)

[void]

Thanks for the feedback raccoon and therube,

group_colors is just an experiment at the moment.
There would need to be a toggle as you suggest, eg: View -> Group Colors

Group colors works best when performing a duplicate search.
Otherwise, each item has it's own color.

For example:
Sort by size and search for: duplicated:

Another ini setting might work instead: dupe_group_colors which only applies when searching for duplicates.

(In 2., note how the [two different] pinks "merge" [to my eyes].)

That is the limitation with this method.
In your 3). size screenshot, the same color is even used for different sizes.

Using a horizontal line to separate groups might help..

[therube]

Group colors works best when performing a duplicate search.

That's it in a nutshell.



(More to follow, later...)

[therube]

(More, but no time at present to clean it up, so more, rambling...)

Highlighting (sorted by):

Path, works well
- generally there are enough like paths to for a listing by path to be relevant
- further, it allows you to "see" different paths without /looking/ at an overflow
(as in: c:/i don't care/i don't care if you don't want me/
c:/i don't care/i don't care if you don't want me/i put a spell on you/
& if: everything after |IF| was in an overflow, the coloring points out that
you're dealing with 2 different paths & not just 1

Name, eh
- there are collisions (same color turned up on both a file before & a file after
a matching pair
- if your fileset doesn't have a lot of dup'd names, eh, it's very busy
- if only dups were highlighted, that would be ideal

Size, some potential
- 4 consecutive collisions (all ended up same color)

Ext, can't really see much use there, but likely to work well
- again two alternating sets of colors, with white for non-dups, would be much more friendly
(well unless you were expecting individual exts to be in differening color, but i don't
really see the point there?)

Date, takes time into consideration (i noticed that yesterday)
- maybe if date, in this case only meant date (& not time - except for those where time matters )

Length,

my idea is that you want duplicates (based on Property) to stand out from non-dups,
(& from each other if you have consecutive but different dups), with "white" being
the non-dup color; so going down a listing, sorted in whatever manner
white
white
white
blue
blue
white
blue
blue
blue
blue
white
white
white
blue
blue
blue
blue
yellow
yellow
yellow
red
red
red
red
red
white
blue
blue
white
blue
blue
white
blue
blue
yellow
yellow
red
red
red
white
white
white
white
white
blue

in a duplicate file finder, you're only dealing with dups, so you can get away with two colors only
here, since you have dup & non-dup, if you reset color after every non-dup... with that, potentially,
you might only need 1 color, but for the time where more then one is need, you use the minimal number
required simply by repeating color after every break...

audio:tull
& it highlights "audio:" (audio: file extensions; mp3, m4a, m3u, ...)
- unexpected & can't say, wanted

note the \CORRUPT\ files
- typically highligted in a different color - even though the "Length" is the same
- (anything in CORRUPT is just that & while it may say "Thick as a brick", & "43:26"
- it is not! heh. it may even play, or play somewhat, or not at all, but it it not
[any longer], Tull, heh.)


in general, in practice, for what & how i've looked so far, it's not there, yet.
too busy, too noisy. simpler, fewer colors, that clearly identify dups, as it is
/sometimes/ i can look & see, & say oh OK, but most of the time its... tiring.


maybe only have this in effect when there is a DUPE in effect?
maybe only have this in effect when there is a DUPE in effect AND you're sorted by said DUPE column?
- with that, you can get away with only two colors
- that easily & clearly deliminates dups

- i do a 'Find Length Dup', & with highlighting, without question, without having to /look/
at any actual lengths, i can /see/ exactly what are dups, & i can quickly & clearly see
that i my current search, there is nothing more that i need to do with said set of files
- now that i know that, i can then UNIQ said set of files, cutting my listing down
- at least in half,


Duplicates: 'Find Length Duplicates', Sorted by Length.
In this case, except for the multitude of colors, highlighting does help (IMO).
Since these are dups, & grouped by the Length, coloring would point out things like same length, different Name (where I then may want to adjust the names to make them agree. [In this case, in most instances, the names will agree too - but that won't always be the case.]). (Oddly, for whatever reason, even though Thick As A Brick - Track01 all have the same Length, the /corrupt/ version is colored differently - which happens to be kind of helpful, in this instance.)
This is (mainly) duplicated pairs. If there were larger swaths of duplicated data, coloring would help in distinguishing between data sets.
.

Everything does Tull really need highlighting.png (50.8 KiB) Viewed 43064 times

[raccoon]

There would need to be a toggle as you suggest, eg: View -> Group Colors

Maybe give it a negative column toggle as well. As in "Disable Group Colors" per column for when the global View -> Group Colors option is enabled.
Maybe make it so the colorization is contained to just a single column instead of the whole line.
Maybe, instead, make this a search syntax command, such as sort-colorize:size, and the colorization stays put regardless of a user's column header click sorting.

I personally don't find it very useful since column sorting already groups the data inherently. I find line colorization useful in situations where data is NOT already sort organized, as in, the colorization behaves as a second-sort. It's not useful when it just correlates to the primary sort ordering.

I discontinued testing this feature after 2 days because it reduces readability contrast, and I didn't find it useful for the reasons above.

[void]

Thank you for the feedback therube and raccoon,

Everything 1.5.0.1288a makes some changes to finding duplicates:

removed group_colors ini setting.
added dupe_group_colors ini setting.
fixes an issue with calculating the total size when finding duplicates.
fixes an issue with clearing find duplicates.
DUPE is only shown in the statusbar when right clicking a column header and clicking find duplicates. (it is not shown when searching for duplicated: to avoid confusion)
You can now right click the Find xxx duplicates menu item option for more functionality:




To enable duplicate group colors:

• In Everything, type in the following search and press ENTER:
  /dupe_group_colors=1
• If successful, dupe_group_colors=1 is shown in the statusbar for a few seconds.

Group colors are now only shown when you are actively searching for duplicates.

[therube]

You can now right click the Find xxx duplicates menu item option for more functionality

That's not obvious.
If not an arrow, then perhaps even a tiny tic mark - just to clue one in.


Perhaps if you hoover (mouseover) DUPE, DISTINCT..., if it displayed the actual filter in effect (might be helpful)?
(Terminology; Including First/Except First, might be a bit confusing [to me].)

file:

, with Find Unique enabled, might turn up some interesting tidbits?
Or maybe

file: \some\dir\iwantowatch

(again with Find Unique enabled).
(Similar ways to get similar results, but it's kind of neat.)

[therube]

As it is now (1288), you are only coloring on a Find...Duplicates.
Since you are doing that, any reason to use rainbow rather then simply two colors?

In current situation, there are still (color) collisions (sets of files, different Properties, but ending up colored alike & together).

Are you specifically coloring "nul" Properties as white?

[therube]

Coloring is lost once you perform an action that changes (moves away from) the Find...Duplicates operation.
Like if I Find Length Duplicates, then sort on Name...

I'll have to see how that plays out...
(Often I'll do a DUPE of some sort, to get expected coloring, then change the sort & may not want to lose the coloring...
I'll have to see...)

[harryray2]

Thanks...this is so much better.

[harryray2]

@void on your screenshot you show the find name duplicates, which I have, but also 4 other options. I don't appear to have these.

[therube]

You have to right-click the 'Find...Duplicates' item.
It does not expand or display, automatically.

[harryray2]

Got it...thanks.

[void]

Thanks for the feedback therube,

You can now right click the Find xxx duplicates menu item option for more functionality

That's not obvious.
If not an arrow, then perhaps even a tiny tic mark - just to clue one in.

I agree, ideally a SE pointing triangle on the right: ◢
Not something I can do with the stock menus, should be something I can do with my own menus one day.

I don't expect these items to be used often.
I am probably wrong, but at-least you can access and test the functionality for now.

Coloring is lost once you perform an action that changes (moves away from) the Find...Duplicates operation.
Like if I Find Length Duplicates, then sort on Name...

This will be fixed in the next alpha update.

Since you are doing that, any reason to use rainbow rather then simply two colors?

Everything will need as many colors as possible to reduce collisions.
It's not feasible to alternate group colors for live results.
It might be doable for the visible results, but it will jump around when you scroll.

Are you specifically coloring "nul" Properties as white?

Yes.
Is this OK?

Perhaps if you hoover (mouseover) DUPE, DISTINCT..., if it displayed the actual filter in effect (might be helpful)?
(Terminology; Including First/Except First, might be a bit confusing [to me].)

The correct status should be shown, eg:
DUPE
DISTINCT
!DUPE
!DISTINCT

The terminology is based on Excel.
In Excel, they have Find Duplicates and unique -> Duplicates (Except 1st one) / All duplicates (Including 1st one) / Unique values only / All unique (Including 1st duplicates)

audio:tull
& it highlights "audio:" (audio: file extensions; mp3, m4a, m3u, ...)
- unexpected & can't say, wanted

prefix your audio filter search with nohighlight: to disable this.
For example:
nohighlight:ext:aac;ac3;aif;aifc;aiff;amr;ape;au;cda;dts;fla;flac;it;m1a;m2a;m3u;m4a;mid;midi;mka;mod;mp2;mp3;mpa;ogg;opus;ra;rmi;spc;rmi;snd;umx;voc;wav;weba;wma;xm

[void]

Coloring is lost once you perform an action that changes (moves away from) the Find...Duplicates operation.
Like if I Find Length Duplicates, then sort on Name...

This will be fixed in the next alpha update.

Fixed in Everything 1.5.0.1289a.

[therube]

Are you specifically coloring "nul" Properties as white?

Yes.
Is this OK?

Yes, fine.

[therube]

See, Length: ms are being taken into consideration (breaking highlighting).

[raccoon]

> > You can now right click the Find xxx duplicates menu item option for more functionality
> That's not obvious.
> If not an arrow, then perhaps even a tiny tic mark - just to clue one in.
I agree, ideally a SE pointing triangle on the right: ◢
Not something I can do with the stock menus, should be something I can do with my own menus one day.

Actually, the stock menus do support that character just fine, at least in Windows 7. Give it a spin. I also think the ✚ character looks just as nice as ◢ in Windows menus.

menu-test.png (3.54 KiB) Viewed 41713 times

If you want it right-aligned, put a tab 0x09 character before it.

[void]

Thank you for the suggestion raccoon,

\t◢ was one of the first things I tried, but I didn't like the look.
I wonder if there is a smaller triangle character..

I will experiment with a custom drawn item.

[raccoon]

✚ ★ ⦿ ... (3 regular dots)
Something's better than nothing in an experimental Alpha ¯\_(ツ)_/¯

menu-test2.png (2.98 KiB) Viewed 41301 times

[void]

Everything 1.5.0.1290a will now use dupe_group_colors when searching for duplicates:/duplicated:/finddupes:

[Kort]

Hello Void. I use HashMyFiles with the colored grouping and really like the color highlight grouping that you have added to Everything 1.5a for 'duplicated' files.

In Everything, I have Alternate row color enabled (Options > General > View) for the ease of seeing the rows. However, this causes a problem with the current (1290a) dupe_group_colors INI setting because the highlighted grouping appears as two different color shades within the same group, breaking the visual effect of the distinct groups.

As a suggestion, could you temporarily disable the Alternate row color setting whenever Everything is actively displaying files as duplicated grouped highlighted colors? Thanks!

[NotNull]

In my opinion, it makes much more sense to create a separate interface for these advancedd duplication searches, like Menu:Tools > Find Duplicates (or through some kind of a plug-in interface).
To do this the right way will probably have too much limitations in the current UI.

[raccoon]

I'm not sure a separate interface would be ideal, as it could only serve to limit the flexibility of your duplicate searches and the nuanced whittling down of results to be deleted or moved or renamed. It may require a nice tutorial, but I think all the capability exists in the current interface.

I would still add Checkbox Select for people who aren't very nimble with Shift/Ctrl multi-select (most average people).

The alternate line color shading doesn't bother me, because they're just shades of the same color hue without ambiguity. Red is red.

[Claudio Salvio]

...
removed group_colors ini setting.
...

Hello David,

I am sorry that you have removed this option, I ask you to reconsider.

There are use cases where it can be useful and it would be nice to be able to activate it in those situations.

For example: we do a search with certain criteria that does not involve duplicates of any kind.
We sort by any of the visible columns and the elements with the same value in the column are colored.
Specifically, if I sort by path, all elements with the same path have the same background color.
The same with the different date columns, etc.
There are cases where one uses Everything for analytical purposes and this facility could be very useful.

Greetings,
Claudio Salvio

[void]

Thank you for your feedback Claudio Salvio,

I'll add this setting back in the next alpha update.

[void]

Everything 1.5.0.1304a re-adds the group_colors ini setting.


To always show groups of the same value in different colors:

• In Everything, type in the following search and press ENTER:
  /group_colors=1
• If successful, group_colors=1 is shown in the status bar for a few seconds.

[void]

Everything 1.5.0.1316a adds a group-colors: search to temporarily enable group coloring.

To temporarily show group colors, include the following in your search:

group-colors:

[therube]

I find coloring very useful, very efficient in determining...
Often I can rely solely on color & dismiss all else.
CHK (hasher) in particular, I am specifically looking for dups, so when I glance at its window, & see nothing but yellow, I know, I'm good. When I see, white, then I have to actually look & think...*

Everything too.

But...

- as it is, with color collisions & color-blindness...
[old age, poor eyesight, tiredness, heh, lol...]
makes it very difficult to efficiently determine
dupes... at times...

Collisions in particular.**
Sometimes, often times now, I'll have 2, 3, 4... separate sets of files, all banded together in a single color, & at that point instead of solely relying on color, I then have to look at other attributes, like hash. (And if you're sorted by hash, well, they are going to be similar too, so then you have to look again...)

And then close colors that are hard to distinguish from one another.

If at least collisions could be avoided, that in itself would be of benefit.
.

Everything color highlighting.png (44.14 KiB) Viewed 23068 times

*Usually I drag sets of files into CHK that I'm expecting exactness, so a sea of unending yellow is good.
(The screenshot does not reflect that usage.)

**That green blob actually has 3 sets of collisions in it. So in that respect you cannot glance, see a band of colors & "know". You actually have to look further. Also, in this case, the files in that green blob happen to be grouped together, one after the other, but that need not be the case - as in a 3197544 could be between a pair of 3286688's & the other 3197544 could have ended up between a pair of 3281056's.

[void]

Everything is using a XOR hash on each nibble to calculate the color.

There will be collisions.



I am considering an option to show a dividing line between changes (instead of colors)



Another option I am considering is to build and maintain a color table so that each change is contrasting.
You can still run into collisions. However, only when you add or remove from the results.

[NotNull]

build and maintain a color table

Not to be confused with a rainbow table!

[ChrisGreaves]

RFE: Find Duplicates - Highlight Alternating Dups

Hello All.
This is a topic full of meat. I am documenting the Find Duplicates features at the Beginner level and as usual add my two-cents worth. I have to re-read this topic to extract its full value - the topic is only the first of eleven topics that turned up in my search

(1) I noted (somewhere) Void's comment that the result List is "Live" (his term), and this seems to me to be part of the basic philosophy of Everything. So a constraint on development might be that anything and everything that affects the appearance of the Result List should be applied and updated in real time. That is certainly the way a simple search works as I type in the search string character by character. Any change to any specification or setting that could change the Result List, but does not change the Result List, would then be defined as an error/bug.

(2) From my exalted position as a perpetual beginner, I suspect that the most popular use of the entire "duplicates/unique" scene will be near-beginners searching for duplicates by name, and possibly by date modified and/or size. I'd bet 90% of our executed(1) "duplicate/unique" are looking for "duplicate by name", and that 98% of our executed "duplicate/unique" are looking for "duplicate by name" or for "duplicate by date" or for "duplicate by size". That being the case, this simplest Find Duplicates should have a consistent and simple output. I think that two contrasting colours will do the trick. I will say "three" if we add white because I have seen posts in this topic about neutral entries. Given that the result List is Live, electing to include non-duplicate files (?) should produce a near-instantaneous change in the result List.

(3) I understand that group-colors is a binary toggle with a numeric parameter. "0" is disable, "1" is enable. I am bold enough to ask that, for the remaining 2% of us who know what we are doing and go beyond the 98% of our executed "duplicate/unique", they might be better served by an extended set of numeric values:-
group-colors=-1 restore default
group-colors=0 no group colors
group-colors=2;4;5;7;12 assign these colours to a rotating set of distinct colours.
group-colors=1-2;2-4;3-5;4-7;5-12 which should be read "if there is only one duplicate, colour the files color2; ,,, if there are five or more files duplicated use color12"

FindDuplicates_10.png (112.81 KiB) Viewed 21523 times

In this "Duplicates by date=modified" Result List, the colour bands are practically useless. the second, third, and fourth rows look different if I really screw up my eyes, but they are all "pastel green" at first glance, and that leads to my lack of faith in all the colour banding.
W3Schools has a set of ten colours that should suit 95% of that 2% of specialist users.

Untitled.png (15.35 KiB) Viewed 21523 times

I would have little objection to the group-colors list expressed in hex or RGB or ...

Thanks, Chris
(1)So if I have seven shots at finding MP3 tracks by name, date and size until I manage to get the Result List I want, that counts as SEVEN, not as ONE, exercises in locating my duplicate tracks.

[therube]

the result List is "Live"

Not always.
Like DISTINCT: will block "updates".
And even in times when it is not [updating], there could still be "updates" to it... depending.

but does not change the Result List, would then be defined as an error/bug

Or... a feature, depending on how you look at it.

I'd bet 90% of our executed(1) "duplicate/unique" are

And it's a good thing that we don't know. As "telemetry" is always skewed & kills innovation.

if there is only one duplicate, colour the files color2; ,,, if there are five

I'd think that is the crux of the issue, you don't know ahead of time how many, & to find that out - takes time...

Duplicates by date=modified

That's why I asked about, dupe:dm, tolerance ?

Note that if you "Find Date Modified Duplicates" (& you have coloring enabled) you can see "irregular" results.
But if your Find is some other, say Find Name Duplicates, while the results are then sorted by name, if you then click the Date Modified (column header), the dates will sort & display "correctly".

(That is typically how I interact, first by some other "property", then by Date, if need be, & in that respect dates do display "correctly". Likewise I rarely, if ever did I do a Find Date Modified Duplicates, which is also the reason I didn't realize that "date dupes" take nanoseconds into consideration, till now.)

[ChrisGreaves]

if there is only one duplicate, colour the files color2; ,,, if there are five

I'd think that is the crux of the issue, you don't know ahead of time how many, & to find that out - takes time...

But we DO know ahead of time!
The user provides a definition for "break in sequence", where sequence is defined as - say - Name, Date, Size.
The user defines a colour sequence "group-colors=1-2;2-4;3-5;4-7;5-12"

Everything assembles the Result List in the user-defined sequence, and during assembly checks for a break in sequence.
When the break in sequence occurs, Everything can ask "Now, how many items were collected in this most recent set?" and apply the user-defined colour set:-
Case 1 item: Use colour 2 (group-colors=1-2;2-4;3-5;4-7;5-12
Case 2 item: Use colour 4 (group-colors=1-2;2-4;3-5;4-7;5-12
Case 3 item: Use colour 5 (group-colors=1-2;2-4;3-5;4-7;5-12
Case 4 item: Use colour 7 (group-colors=1-2;2-4;3-5;4-7;5-12
Case 5 or more items: Use colour 12 (group-colors=1-2;2-4;3-5;4-7;5-12

Cheers, Chris

[therube]

But if your Find is some other, say Find Name Duplicates, while the results are then sorted by name, if you then click the Date Modified (column header), the dates will sort & display "correctly".

That is NOT correct.

[void]

dupes colors is off by default because groups may share the same color.



I will consider the option to customize the colors.
I will consider the option to use only one alternating color.
I will consider the option to change the group color when values change for the current view only.

Thank you for the suggestions.

[ChrisGreaves]

I will consider the option to customize the colors.
I will consider the option to use only one alternating color.
I will consider the option to change the group color when values change for the current view only.

Hi Void. I am not sure who you are replying to here.
The first image in my post above confuses me with its grouping colours.
In [particular the 2ns, 3rd, and 4th rows appear to be very-slightly-different shades of pastel green.
As the result List is built, each change of group ought to be flagged by a significantly different colour, rather than a subtle shade of the same colour.

I accept that the boundary lines are a much better guide than the current coloring method.
Thanks, Chris

[Christian.Ziegelt]

Hi everyone,
I tried to read myself through the whole topic here, but wasn't able to find my solution.

(1) I'd like to se a list matching my search - with all results, duplicate or not - like:
"SFW.*.pas"

(2) I'd like to sort the list for example by Name, as I want to compare all files with the same name (could be sometimes Path, or....)

(3) Now, I'd like to add the SHA-256 column to understand which files are in which state

(4) Then sort as second sort order by SH-256

(5) Finally I'd like to color all lines in groups by the column SHA-256

The result would be a list sorted by name and then by SHA, colored with SHA to make it visible which files are changed.

All settings that I've read so far are not reflecting this.
The nearest I can get is sorting by SHA column and using groupcolor: option in the filter

Any ideas on this ? Thx in advance

[NotNull]

Not sure what you want, so if the following does not give the desired results, please post your own search queries and in what aspect they failed.

Code: Select all

sfw.*.pas   dupe:size;sha-512   sort:size;sha-512

[Christian.Ziegelt]

thanks for the suggestion.

I'd like to see the results sorted as in my picture (by name, then SHA-256) and then color in groups regarding the SHA-256 column - to identify different groups of the same files.

I can't use dupe: as it filters out non-dupe files. But I need to see all occurrances of a file.

image.png (404.16 KiB) Viewed 4659 times

[void]

Please try the following search:

sfw.*.pas addcolumn:sha256 sort:name;sha256 groupcolors: grouplines:

addcolumn:sha256 = temporarily add the sha256 column (it's best to only show this column when needed)
sort:name;sha256 = sort by name, then sha256.
groupcolors: = show group colors.
grouplines: = show group lines.

[Christian.Ziegelt]

ah - yes - at least I can see the bounds to the next block now.
But unfortunately, the groupcolor still seems to be bound to the sort field ?

Is there a way to define what to color ?

Something like

Code: Select all

sfw.*.pas addcolumn:sha256 sort:name;sha256 groupcolors:sha256 grouplines: