This also simplifies the start condition greatly. The "corner" circles (as the algorithm calls them) are all computed as tangents to a pair of circles, thus eliminating the special circle+segment or segment+segment cases. They are computed to pass through the corners of the bounding box and converge toward the actual sides when the radius grows. The picture shows what the 4 bounding circles look like when the radius is decreased. Instead of segments defining the bounding box, I used circles with "infinite" radii, that can be considered a good approximation of lines: I used a trick to make the computation more regular. I tweaked it quite a bit, but I think it does basically the same thing. PS: others Thanks for the ideas but right now I think the combination of size and colors ultimately should be avoided because it needs too much explanation.Here is a go at the implementation of your algorithm. Only empty files would be totally grey (like now). the same blue as the circles), else it would just be confusing. With this system I'd keep it at just one color (e.g. And it can be easily enlarged by adding pixels.
With the current 50 pixels width of the bar it could hold a maximum of 2^50 = 1 PB (PetaByte, or more exactly Pebibyte) which is enough for current files. Each pixel is double the size of the previous: 1 2 4 8 16 32 64. OH, wow, inspiration hit me! A super-cool logarithmic approach would be let's call it a "Binary Bar". Well, I totally agree with this! The current way is rubbish.
Don't you think, is's super misleading/un-intuitive? Everybody would instantly think, the first file is largest, wouldn't he? But I'm not sooo happy with the current implementation, see the attached file.
Hello, I think, a quick visual representation of file/folder sizes can be very helpful.
0 kommentar(er)
