Hidden Color Filter Feature

[admin]

The next beta (v9.60.0112) will support color filters based on file size (files only, list only -- not folders, not tree).
Add these examples to the top of your color filters list (in LM / Color Filters) to see and believe:

Code: Select all

+/sizemax:0>4199E0,CDCFE2
+/sizemin:1000000>DE4466,E0DECF

The first means: color all files with a size of maximally 0 bytes.
The 2nd means: color all files with a size of at least 1000000 bytes.

Why hidden? Damn it, but I have no time to document it.
Why did I add it? Damn it, I needed it!

[RalphM]

If you copy/paste it to the List Mode, do it without the leading "+" for it to work...
In Editor Mode the "+" can be copied and is interpreted as set it active.

[TheQwerty]

If you copy/paste it, do it without the leading "+" for it to work...

... or paste it into Editor mode.

EDIT: As you added via Edit.

[TheQwerty]

I'm not crazy about your choice of pattern here... I'd prefer to see:

Code: Select all

/size:min:max

If either argument is omitted it is unbounded.

With the way you have it now it can be confusing to do something like:

Code: Select all

+/sizemax:0>FF0000,
+/sizemin:10>00FF00,
+/sizemin:1;/sizemax:9>0000FF,

Because in the last pattern they are OR-ed thus the order of the filters becomes extremely important.

You also made this impossible:

Code: Select all

+/sizemax:0>FF0000,
+/sizemin:10>00FF00,
+/sizemin:5;/sizemax:9>00FFFF,
+/sizemin:1;/sizemax:4>0000FF,

as well as finding a file of an exact size:

Code: Select all

+/sizemin:42;/sizemax:42>101010,

Where my suggestion would make it:

Code: Select all

+/size::0>FF0000,
+/size:10:>00FF00,
+/size:5:9>00FFFF,
+/size:1:4>0000FF,
+/size:42:42>101010,

And it removes the dependence on the sort order so I can define them in a more sensible manner:

Code: Select all

+/size::0>FF0000,
+/size:1:4>0000FF,
+/size:5:9>00FFFF,
+/size:10:>00FF00,
+/size:42:42>101010,

Further, not that it's a big difference but you'd only have to document one pattern instead of two plus a note on the importance of ordering.

[admin]

If your regions overlap then order becomes important as well. IMO there is not much won overall. My current scheme is more intuitive I think.

[TheQwerty]

If your regions overlap then order becomes important as well. IMO there is not much won overall. My current scheme is more intuitive I think.

I wasn't trying to eliminate the importance of order by rather lessen its impact.

And yes I realize I did mistakenly claim some of the possible impossible with your scheme, though the fact that I so easily made that mistakes points out that the current scheme is not so immediately intuitive.

Code: Select all

+/sizemin:10>00FF00,
+/sizemin:5>00FFFF,
+/sizemin:1>0000FF,
+/sizemin:0>FF0000,

Still no easy way to highlight files of a specific size, though.

[j_c_hallgren]

If your regions overlap then order becomes important as well. IMO there is not much won overall. My current scheme is more intuitive I think.

Looking at this and using TheQwerty's examples, I find his idea of just a 'size' and both limits to be very intuitive and less wordy as well...sorry, Don.

[admin]

+/size::0>FF0000,
+/size:10:>00FF00,
+/size:5:9>00FFFF,
+/size:1:4>0000FF,
+/size:42:42>101010,
[/code]

Why the second ":"? It looks better (more intuitive) to me with a "-" instead:

Code: Select all

+/size:0>FF0000,
+/size:10->00FF00,
+/size:5-9>00FFFF,
+/size:1-4>0000FF,
+/size:42>101010,

Or:

Code: Select all

+/size:0>FF0000,
+/size:-4>0000FF,
+/size:-9>00FFFF,
+/size:10->00FF00,

[SkyFrontier]

I'm trying to set a visual filter to tell me the safest value Nero can handle when burning a 702.5 MB data CD.
Bit calculators tell me the value is 736624640 bytes (1024 bytes)/702500000 (1000 bytes).
Forums, 736970752 (reporting as 702 MB despite the value being larger - rounded, perhaps...).
And I can't remember the name of a tool I had to create dummy files and effectively try a real burning session...
Can someone enlighten me on the safest, allowed for burning value?
Thanks!

[TheQwerty]

Why the second ":"? It looks better (more intuitive) to me with a "-" instead:

I only picked ':' because you were using it to separate the pattern and value already, so I figured it would be safe choice that probably wouldn't conflict with your existing parsing.

'-' will make an omitted min look like a negative max, and while that makes zero sense in this instance I'm not sure it's the best alternative. Then again it's also common usage when writing 'number through number'.

Using '.' or ',' might be confused as a decimal place (especially since there may come pressure in the future to allow the use of units other than bytes and it might be nice to do 1.5MB then instead). I believe some programming languages use '..' when using indexes to slice an array, so maybe that's an okay choice?

All told, I don't really have a preference of what you use to delimit them, I'm just thinking of the functionality.


If instead of dealing with omitted character you wanted to make it:
/size:min-max;>RRGGBB
/size:<n;>RRGGBB
/size:>n;>RRGGBB
That's cool too, but since > already has special meaning it's probably not as easy.

[admin]

Why the second ":"? It looks better (more intuitive) to me with a "-" instead:

I only picked ':' because you were using it to separate the pattern and value already, so I figured it would be safe choice that probably wouldn't conflict with your existing parsing.

'-' will make an omitted min look like a negative max, and while that makes zero sense in this instance I'm not sure it's the best alternative. Then again it's also common usage when writing 'number through number'.

Using '.' or ',' might be confused as a decimal place (especially since there may come pressure in the future to allow the use of units other than bytes and it might be nice to do 1.5MB then instead). I believe some programming languages use '..' when using indexes to slice an array, so maybe that's an okay choice?

All told, I don't really have a preference of what you use to delimit them, I'm just thinking of the functionality.


If instead of dealing with omitted character you wanted to make it:
/size:min-max;>RRGGBB
/size:<n;>RRGGBB
/size:>n;>RRGGBB
That's cool too, but since > already has special meaning it's probably not as easy.

> would indeed be unnecessarily problematic.
I think - is totally ok in this context (common usage, as you said already). I currently see no heavy obstacles, but will wait a little before I change it...

[TheQwerty]

> would indeed be unnecessarily problematic.

Thinking back you could avoid overloading '>' with:
/size:min-max;>RRGGBB
/size:<n;>RRGGBB
/size:n<;>RRGGBB

I think - is totally ok in this context (common usage, as you said already). I currently see no heavy obstacles, but will wait a little before I change it...

Yeah, '-' should make perfectly fine sense given the context.

[admin]

> would indeed be unnecessarily problematic.

Thinking back you could avoid overloading '>' with:
/size:min-max;>RRGGBB
/size:<n;>RRGGBB
/size:n<;>RRGGBB

Well, "n<" will raise questions... I know my users (a little)...

Actually I think it could be parsed like this, but the ">" before the color starts looking a bit stupid now...
/size:min-max;>RRGGBB
/size:<n;>RRGGBB
/size:>n;>RRGGBB

[admin]

OK, I worked it out and am satisfied with the following now:

Code: Select all

+/size:0 >4199E0,CDCFE2
+/size:<500 >004080,ABBBD3
+/size:2000-3000 >EEE033,585858
+/size:>100000 >FFFFFF,000000

(The blank before > is just for views, not necessary.)

You get it only tomorrow, of course.

[TheQwerty]

OK, I worked it out and am satisfied with the following now:

Code: Select all

+/size:0 >4199E0,CDCFE2
+/size:<500 >004080,ABBBD3
+/size:2000-3000 >EEE033,585858
+/size:>100000 >FFFFFF,000000

(The blank before > is just for views, not necessary.)

Looks good!

You get it only tomorrow, of course.

(Emphasis mine).. I'm pretty sure this feature will be useful beyond just tomorrow. I'd like to see it as part of XY for at least a couple of weeks, maybe more! But keeping v9.60.0113 (or whatever) around just for this feature probably won't be worth it to me.