[Suggestion] String meter vertical autosize with ClipString

[killall-q]

ClipString currently does nothing if W and H are not both set, except insert unnecessary ellipses where the text was going to end. What I'm suggesting is that with ClipString=1 and only W set, a string meter will automatically increase its height when text overflows to the the next line. This should work with Y=#R allowing stacking of text boxes. Ideally if SolidColor is set the background should extend to the set width regardless of where the text ends. This suggestion should not interfere with any current functionality as far as I know.

This would expand the possibilities for sidebar and notes skins where text is dynamic making a set height inviable.

So sorry for making a suggestion right after a major release...

[jsmorley]

I like having the ability to have a feed that is one line each and is truncated with ... I sorta think it works great that you can have it any way you want right now with no ClipString, ClipString=1 and no H or ClipString=1 and H.

[killall-q]

Sorry, I don't see a difference between 2, 3, and 4. They just replace the last few letters of the string with ellipses without actually saving any space. So 1 and 5 are the ways the only sensible ways to use string meter right now, and 6 is a problem for the inattentive or those who want to allow font flexibility. My suggestion would only replace 3, which is currently useless, and provide a robust solution for 6.

Edit: 5 is how you truncate to a single line, but if the height is too small it'll cut off the tails of g's and such. The room for error is excessive IMO.

[jsmorley]

I don't agree that 3 is useless. Sorry. I use it today on my Google News feed. Before we argue any further, let me say it there is no possibility that we would change something like that in a way that makes an existing skin work differently than it did before. We just never do that.


I'd be ok with a new ClipString=2 or something that automatically figures out the height, but I'm not sure that would be easy given how variable fonts, particularly 3rd party ones from DaFont and such, are in size and structure.

I understand it can take some trial and error right now to make sure the H is what you want, but I prefer the flexibility of leaving off H and having it truncate with ..., setting the H so I get two lines, or three lines, or four lines as desired to fit my layout, then it truncates with ... if needed, or setting the H big enough to be sure I get it all. In my opinion, there is nothing wrong with the current approach.

As I said, a whole new optional setting that tries to figure it out is fine if possible, but in my opinion flawed. It almost REQUIRES that you use relative positioning on following meters or they will be overlaid if you get more text than expected, and that may not be what the author wants in his design.

[killall-q]

I see where there would be a use for what you're saying. 2 and 4 provide the same benefit though.

Edit: It's the functionality I'm suggesting that really matters to me, not how it's implemented. So yeah, height autosizing, anyone?