Suggestion: String Meter enhancement - Redux

[SilverAzide]

My original posting with an enhancement suggestion was met with silence and cricket sounds, so I thought I ask one more time.

Currently, the String meter formats numbers using a "variable scale, fixed precision" methodology. ("Scale" is the total number of digits, not including signs and decimals, and "precision" is the number of digits after the decimal.) For example, using "NumOfDecimals=3", you get output like this:

Code: Select all

3.141      (scale=4, precision=3)
314.159    (scale=6, precision=3)
3141.593   (scale=7, precision=3)
314159.265 (scale=9, precision=3)

This style of formatting means that the total number of digits in the resulting string, and thus the string's length, is somewhat unpredictable. Designers must include extra whitespace after the numbers to account for large values, so if additional design elements follow the meter, there is a possibility that the data can overflow one meter into another. Also, when using this in meters with rapidly changing values, the meter tends to show numbers that bounce around, as large and small values alternate.

The suggestion is to allow an option for formatting numbers using a "fixed scale, variable precision" methodology (the opposite of NumOfDecimals, and would imply AutoScale). With this, you'd specify the scale (the total number of digits only), so the output using the same numbers above would be (using a scale of 6):

Code: Select all

3.14159  (scale=6, precision=5)
314.159  (scale=6, precision=3)
3141.53  (scale=6, precision=2)
314159   (scale=6, precision=0)

This can result in a more uniform appearance when displaying sets of values and will allow more predictable text placement.

I created a plugin to do this to illustrate the difference in the String meter output appearances. Notice the existing formatting (left graphic) creates a "ragged" appearance where numbers and suffixes don't line up, whereas when using a fixed-scale format (right graphic), the numbers are arranged in neat columns, regardless of whether the numbers are huge or tiny.

Thanks for listening!

[jsmorley]

I'm not sure I agree with this. I understand the idea, but really from a "positioning" standpoint this really doesn't help that much unless you use a "fixed width" font as well. The length in pixels of a numeric string has as much to do with which characters are in it and what font face you use, as it does with the number of characters in it.

The fact that your numbers with the kbits/s postfix lined up vertically both left and right has as much to do with the fact that 1.266 and 13.98 happen to be the same length in pixels. Try it with 1.111 and 9.999.

Text=1.266#CRLF#13.98#CRLF##CRLF#1.111#CRLF#9.999

1.png

The top two are perfect. The bottom two don't line up left or right...

So while it might be somewhat visibly pleasing to have a fixed number of characters in a numeric string, I think the practical use is pretty limited. Just my opinion, and beauty is in the eye of the beholder, but if you can't get them to line up "exactly", then sticking a zero or two on the end and "floating" the decimal point around just ends up looking like you "tried" to line them up, but failed...

I'm not strongly opposed to it or anything. A lot of my hesitation is that I think this is better viewed as one minor use of a much broader "string formatting" functionality, maybe something like "printf" in C. I'm not convinced that that functionality, were we do do it, should be part of the String meter. My gut reaction is that it is a better fit with the String measure instead.

In any case, you certainly have been heard. I will leave it to the rest of the team to weigh-in as they see fit.

[SilverAzide]

Thanks for listening! I can't ask for more than that!

The column alignment wasn't the biggest attraction to me, the nicest feature mostly is being able to have a predictable string length and not having numbers bouncing around as the values change. I can handle formatting with a plugin if it's super-important, but plugins don't seem to be nearly as efficient as the built-in String meter. I tried to use the String measure, but I'm a regex wimp and the only thing I could figure out how to do was truncate the string to some fixed length, which meant numbers did not get rounded properly. Plus the measure doesn't do all the fancy AutoScale stuff, which is a super-nice thing to have.

[jsmorley]

Thanks for listening! I can't ask for more than that!

The column alignment wasn't the biggest attraction to me, the nicest feature mostly is being able to have a predictable string length and not having numbers bouncing around as the values change. I can handle formatting with a plugin if it's super-important, but plugins don't seem to be nearly as efficient as the built-in String meter. I tried to use the String measure, but I'm a regex wimp and the only thing I could figure out how to do was truncate the string to some fixed length, which meant numbers did not get rounded properly. Plus the measure doesn't do all the fancy AutoScale stuff, which is a super-nice thing to have.

In the meantime, you might look at a Lua script. That can do that kind of formatting easily, and wouldn't be hard to integrate into your skin.

[moshi]

The fact that your numbers with the kbits/s postfix lined up vertically both left and right has as much to do with the fact that 1.266 and 13.98 happen to be the same length in pixels. Try it with 1.111 and 9.999.

depends on the font. the thread starter would not see a difference, as while the font he uses is proportional, the numerals have a fixed width.
try your experiment with Tahoma or Segoe UI (it seems on Windows 8 Rainmeter uses Segoe WP as default)

[MikeG621]

I would like this not so much for "lining it up to be pretty", but this is really talking about Significant Digits which we use a lot in the sciences and engineering. Makes doing layouts a little nicer if you know the number will always be X digits (± a decimal) long. As you said Lua can easily do it, but it'd be nice if it was native.

[jsmorley]

depends on the font. the thread starter would not see a difference, as while the font he uses is proportional, the numerals have a fixed width.
try your experiment with Tahoma or Segoe UI (it seems on Windows 8 Rainmeter uses Segoe WP as default)

"Depends on the font" sorta makes my point though...

[jsmorley]

I would like this not so much for "lining it up to be pretty", but this is really talking about Significant Digits which we use a lot in the sciences and engineering. Makes doing layouts a little nicer if you know the number will always be X digits (± a decimal) long. As you said Lua can easily do it, but it'd be nice if it was native.

I'm not in the business of telling anyone how they should format their skins, All I see it as is "same number of characters, with a decimal point that floats around all over the place and makes it very hard to glance at in a meter and tell what the value really is".

I think in an 8-point font:

2.2344336
2238.3457

Are just jarring, and hard to follow. Doesn't feel like they are even measuring the same thing. "Function following form".

But to each his own for sure.

[SilverAzide]

jsmorley:
In the meantime, you might look at a Lua script. That can do that kind of formatting easily, and wouldn't be hard to integrate into your skin.

Duh, I didn't think of using LuaScript! Genius idea, I guess I'm stuck in my Visual Studio box. I need to get out more often. Tried it, and it works GREAT! Also thanks for the Lua tutorial skin you created, it was extremely helpful.

[jsmorley]

Duh, I didn't think of using LuaScript! Genius idea, I guess I'm stuck in my Visual Studio box. I need to get out more often. Tried it, and it works GREAT! Also thanks for the Lua tutorial skin you created, it was extremely helpful.

Good. I'd be curious to see what you came up with for the Lua, I don't think string.format (printf more or less) can quite do exactly what you want in and of itself, so it feels like you might have to "stringify" the number and do some moderately complicated analysis to handle stuff like numbers that are already longer than the desired length, integers with no decimal, negative numbers, etc.