XYplorer Beta Club

One bar element is 11 px large (100% dpi, 1920x1200) so 10% size difference is just a damn single pixel (for the linear graphic part).

The old bar length is ~50px, -> 5px per 10% *sigh*

Where exactly is the problem that full colorized bars (with user definable colors!) don't solve?
Linear, enough space to display size differences and everyone is able to see the difference between
e.g. orange (for GB) and red (for TB) without the necessity to count bar elements. And if they are
color blind they can choose different colors that match their needs...

The relation between color and size is not intuitive, the relation between length and size is.

The relation between color and size is not intuitive, the relation between length and size is.

Colors require no counting, bar elements do. And the relation between length and size is displayed via the
fill grade of the bar and that with a much higher resolution: 5:1

Hi, it's me again,
Really both systems have their pros and cons. I can also kind of understand why you, highend, want the old way back. But at least the argument about "bars counting" is nonesense. No one needs to count bars. Its a visual impression, more bars = more visual impression. Otherwise, one could use the same logic to say about one long solid bar, that you have to count the pixels. Really.

Regarding the old way about colors:
Even if I could define the colors myself, I could never remember which color is for which size range.

Suggested solution:
A combination of both systems, but in a different way than now (because now needs too much eye training and also highend is right with the scaling issue). I would suggest to have both systems not on top of each other but 1) side by side and 2) again with colors, BUT to have each block in the "logarithmic" bar colored according to the color specified for that range. Then the linear bar on the side of it would be kind of a linear "magnification" of the size range in which the size of file "falls into". In effect, the linear bar would be exactly like it was before.

Benefit:
This way you have the "logarithmic" approach there (as well) and it would be easy to remember the colors for each size range because they would always be there in the "logarithmic" bar. (Ofc, the user should be able to turn each bar off individually, if so desired.)
I attached an illustration: Ofc, this is only a suggestion, as you know. Probably there are better ideas.

Thanks, but I'm quite happy with the one-color-only solution in the current version. There are already so many colors with different meanings all over the place. Your solution would also take more space.

admin wrote:... And it works surprisingly well... ... and it's fascinating to see how the two scales complement each other.

Yes, I can agree now.

How should be interpreted the last square now?

(PS: a couple of things:
- circles for folders are brown, shouldn't bars be the same?
- bars don't mantain their aspect ratio in Touchscreen Mode)

Marco wrote:- How should be interpreted the last square now?
- circles for folders are brown, shouldn't bars be the same?
- bars don't mantain their aspect ratio in Touchscreen Mode

- The darker the bigger.
-
-

You mean the fuller the bigger, right? But how are you filling it, exactly? I see there's a bottom half and a top half...

Marco wrote:But how are you filling it, exactly? I see there's a bottom half and a top half...

See the beta notes..

v19.10.0107 - 2018-08-14 13:10
* Size Graphics: Now the upper half of the bar is linear, the lower half is
logarithmic. Both scales nicely complement each other and you get a pretty
well spread resolution.

Oh yes, silly me!

klownboy wrote:

Marco wrote:But how are you filling it, exactly? I see there's a bottom half and a top half...

See the beta notes..

Or the history of this forum thread.
"Logarithmic" in this context means each pixel stands for a file size twice as much as the pixel before (so always x2 for each pixel). Need to wrap your brain around it, e.g. the log bar filling the MB-range-box almost completely with only one pixel missing, does NOT mean that the file is almost 1 GB BUT that it is about 500 MB (about 1/2 GB) - two pixels missing from the full MB-range-box - still an almost full box - means that it is about 1/4 GB.
Both scales have their pros (and cons). Actually they really do compliment each other nicely. Thx for the implementation, Don.

QUESTION, though, Don:
What are the exact size ranges for each logarithmic pixel? Lets say the first box (byte range) is full: What is the exact range of bytes that the file could have? Is it >= 768 and < 1536 bytes?

autocart wrote:QUESTION, though, Don:
What are the exact size ranges for each logarithmic pixel? Lets say the first box (byte range) is full: What is the exact range of bytes that the file could have? Is it >= 768 and < 1536 bytes?

Good you asked! I got curious, made some checks and found rounding errors. From next beta it's like this:

The first size that completely fills the first bar is 963 bytes:
9.5 * 1024/10 = 972,8

The last size that completely fills the first bar (and nothing else) is 1023 bytes:
10 * 1024/10 - 1 = 1023

For the other bars you replace 1024 (1 KB) with 1 MB, 1 GB, 1 TB ...

Marco wrote: - circles for folders are brown, shouldn't bars be the same?)

grey would be nice as well.

Filehero wrote:

Marco wrote: - circles for folders are brown, shouldn't bars be the same?)

grey would be nice as well.

Already used for "empty".

And brown is a beautiful color: earth, wood, skin, nuts, hair, whiskey...