Date Color Filters

[TheQwerty]

Erm.. Don, I'm surprised you went with a method that relies on static dates instead of one that allows relative time frames.

I would have imagined there'd be greater demand for coloring items that were modified today or yesterday, as opposed to items from/since 2008-01-01. And while that may be possible now, I really don't think modifying the filters every day is an acceptable solution.

Or is v9.70.0026 just the first of some incremental additions for date filters?

[PeterH]

Erm.. Don, I'm surprised you went with a method that relies on static dates instead of one that allows relative time frames.

I'm a bit irritated by the word "instead". I think absolute expressions are (also) good...

...but it's right: relative expressions seem more useful! Like:
- today
- last 3 days
- last 33 hours
- and maybe "yesterday"?

[admin]

Or is v9.70.0026 just the first of some incremental additions for date filters?

You got it. I'm not finished yet... there are a lot of things yet to come...

[TheQwerty]

You got it. I'm not finished yet... there are a lot of things yet to come...

Good, that's what I was assuming, but you know what they say...

Any chance we'll see a way to apply separate background & foreground patterns to items in v2?

For instance the majority of my color filters are changing the foreground color based on extension or attributes, but I'd like to be able to also change the background color based on size or date.

Maybe this could be done through a specific color switch on the pattern so one could have:

Code: Select all

/size: 0>continue,FF0000
desktop.ico;desktop.ini;Thumbs.db>FFAAAA,
New Textfile.txt>AAAAFF,553300

The continue in the first item's foreground color would tell XY to keep processing filters until one is found that defines the foreground (or none are found), so "desktop.ini" of 0 bytes would end up with colors "FFAAAA,FF0000".

But it would not apply any further matching background colors, so "New Textfile.txt" of 0 bytes would end up with colors "AAAAFF,FF0000" instead of the "AAAAFF,553300" that a 1 byte "New Textfile.txt" would have.

EDIT: I pulled these colors out of thin air, so no need to comment on how ugly the combination might be.

[admin]

Maybe this could be done through a specific color switch on the pattern so one could have:

Code: Select all

/size: 0>continue,FF0000
desktop.ico;desktop.ini;Thumbs.db>FFAAAA,
New Textfile.txt>AAAAFF,553300

The continue in the first item's foreground color would tell XY to keep processing filters until one is found that defines the foreground (or none are found), so "desktop.ini" of 0 bytes would end up with colors "FFAAAA,FF0000".

But it would not apply any further matching background colors, so "New Textfile.txt" of 0 bytes would end up with colors "AAAAFF,FF0000" instead of the "AAAAFF,553300" that a 1 byte "New Textfile.txt" would have.

EDIT: I pulled these colors out of thin air, so no need to comment on how ugly the combination might be.

continue... hmm, nice idea... I'll check that...

[TheQwerty]

continue... hmm, nice idea... I'll check that...

Just to note, I'm not sure continue is the best syntax to go with here... this wasn't a suggestion I'd thoroughly thought through.

Originally was thinking a switch at the end: "fore,back,c[ontinue]". Then thought making it a special color argument would prevent users from providing both colors with the switch enabled and wasting time tracking the unexpected results down or making XY search for another match.

I'd really prefer a descriptive word shorter than Continue but nothing is coming to mind. C by itself won't stand out enough since it's also a hex value, and I'm not sure Cont would be clear enough.

[admin]

continue... hmm, nice idea... I'll check that...

Just to note, I'm not sure continue is the best syntax to go with here... this wasn't a suggestion I'd thoroughly thought through.

Originally was thinking a switch at the end: "fore,back,c[ontinue]". Then thought making it a special color argument would prevent users from providing both colors with the switch enabled and wasting time tracking the unexpected results down or making XY search for another match.

I'd really prefer a descriptive word shorter than Continue but nothing is coming to mind. C by itself won't stand out enough since it's also a hex value, and I'm not sure Cont would be clear enough.

I give you time till tomorrow.

[PeterH]

Just tested it a bit...

I wonder: color by filetype, for example, colors the whole matching line, while color by date only colors the name column - the rest of the line is simply un-colored. Why that?

But: could this lead to the solution for a problem I have? As, when coloring by different types (e.g. type and date), that with higher priority wins, while that with lower priority only functions on the poor rest of lines.
Wouldn't it be possible, especially for date-filtering, only to color the date-columns, *independent* from other coloring?
(The same *might* as well apply to other columns, like type or attribute.)

I think this would (at least a bit) resolve the multi-coloring TheQwerty is talking about.

[Joso]

Colors are nice, but how to use them? - How about the ability to use the same syntax in the selection menu - or maybe tag with a date argument - or just selection based on the color of the item(s) - that would be more useful than just pretty colors. I see you're not finished fiddling with dates and colors so maybe this sort of thing is already on the horizon, eh?

[TheQwerty]

Wouldn't it be possible, especially for date-filtering, only to color the date-columns, *independent* from other coloring?
(The same *might* as well apply to other columns, like type or attribute.)

Unfortunately this doesn't offer anything for the non-details views, so at least for me it wouldn't be that useful.

I give you time till tomorrow.

I don't think I'm going to have a better solution so don't delay waiting for me.

Colors are nice, but how to use them? - How about the ability to use the same syntax in the selection menu - or maybe tag with a date argument - or just selection based on the color of the item(s)

Something that has been on my mind for a while now is that it might be approaching time to bring some unity to the Color, Visual, Selection, File Type, and PFA filters. Just as the fact that so many places accepting scripts makes things a bit difficult to manage, I keep thinking that all of these features could be sharing at least some of their data and as a user it would be nice to consolidate the shared aspects into a single place that could be more easily managed.

Perhaps this is something that version 2 of Aliases could improve, I'm not sure, but it's worth considering.

[admin]

Thanks for the input. Let's first see how the new color filters work in real life (before complicating them).

[admin]

I wonder: color by filetype, for example, colors the whole matching line, while color by date only colors the name column - the rest of the line is simply un-colored. Why that?

No, when a backcolor is defined then only colors the name column, else colors whole line.

[jcmn]

Hi

I'm using the color filters for age

I'm using several filters, e.g.

/ageM < 1 h

/ageM < 1 d

etc

by this order. It seems to work, but wouldn't be better to be able to use this kind of syntax:

/ageM < 1 d and ageM >= 6 h

[admin]

Hi

I'm using the color filters for age

I'm using several filters, e.g.

/ageM < 1 h

/ageM < 1 d

etc

by this order. It seems to work, but wouldn't be better to be able to use this kind of syntax:

/ageM < 1 d and ageM >= 6 h

Boolean operators would make it more complex for me and for the users. I currently do not intend to go this way.

This might work for you:
/ageM 6 - 24 h

[jcmn]

This might work for you:
/ageM 6 - 24 h

Yes it's another way to express the ranges.