It is currently March 28th, 2024, 1:23 pm

Changes to ClipString

Changes made during the Rainmeter 2.5 beta cycle and earlier.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Changes to ClipString

Post by jsmorley »

Developer Brian has made a very nice change to the ClipString option in a String meter. There is now a ClipString=2 setting that will dynamically clip or wrap based on combinations of the W and H settings, as well as new ClipStringW and ClipStringH options.

The long and the short of it is that you can now have a string meter dynamically change size to accommodate the string being used, wrapping the string and expanding the meter to fit the entire content.

From the Manual
*******************
ClipString
Controls how strings are truncated (clipped) or wrapped to fit in or expand the containing meter. Valid values are:

0: Disabled. The string will not be clipped or wrapped. (default)
1: Enabled. The string will be clipped with an added ellipsis ... when it exceeds the specified W (width) option on the meter. If the H (height) option is large enough to allow multiple lines, the text is wrapped until the value of H is reached, then clipped.
2: Auto. The string will be clipped or wrapped based on the value of W and/or H. If the width or height are not specified, the meter itself will change size to accommodate the string. This setting works in conjunction with the ClipStringW and ClipStringH options below, to set a "maximum" size that the meter should expand to accomodate the string before clipping.

Note: The changing size of meters when ClipString=2 can cause truncation issues with the overall window size of the skin, unless DynamicWindowSize=1 is set in the [Rainmeter] section of the skin.

ClipStringW
Sets a maximum width that the meter will expand to accomodate the string when ClipString=2. This setting is ignored if the W option is set.

ClipStringH
Sets a maximum height that the meter will expand to accomodate the string when ClipString=2. This setting is ignored if the H option is set.
*******************

Here is a list of scenarios that demonstrates how the feature works with various settings:
    • W is NOT defined:
    • H is NOT defined:
    • ClipStringW is NOT defined:
    • ClipStringH is NOT defined:
    Text will neither wrap nor clip since no limits are set. (This is the same as ClipString=0.)
    The width and height of the meter will be the length and height of the text.
    • W is NOT defined:
    • H is NOT defined:
    • ClipStringW IS defined:
    • ClipStringH is NOT defined:
    Text wraps to the next line only if ClipStringW is reached. There is no clipping.
    The width of the meter is the length of the string or ClipStringW, whichever is shorter.
    The height of the meter depends on the length of the sting. (There is no limit.)
    • W is NOT defined:
    • H is NOT defined:
    • ClipStringW is NOT defined:
    • ClipStringH IS defined:
    This produces the same as scenario 1 since there is no known width limit. EDIT-If the text is already larger than ClipStringH, the text will be clipped.
    • W is NOT defined:
    • H is NOT defined:
    • ClipStringW IS defined:
    • ClipStringH IS defined:
    Text wraps to the next line only if ClipStringW is reached. Text is clipped if ClipStringH is reached.
    The width of the meter is the length of the string or ClipStringW, whichever is shorter.
    The height of the meter is less than or equal to ClipStringH, depending on the string.
    • W IS defined: (ClipStringW is ignored.)
    • H is NOT defined:
    • ClipStringH is NOT defined:
    Text wraps to the next line only if W is reached. There is no clipping.
    The width of the meter is the defined W value.
    The height of the meter depends on the length of the sting. (There is no limit.)
    • W IS defined: (ClipStringW is ignored.)
    • H is NOT defined:
    • ClipStringH IS defined:
    Text wraps to the next line only if W is reached. Text is clipped if ClipStringH is reached.
    The width of the meter is the defined W value.
    The height of the meter is less than or equal to ClipStringH, depending on the string.
    • W is NOT defined:
    • H IS defined: (ClipStringH is ignored.)
    • ClipStringW is NOT defined:
    This produces the same as scenario 1 since there is no known width limit. However, since a H is defined, the height of the meter will be H. EDIT - If the text is already larger than H, then the text will be clipped.
    • W is NOT defined:
    • H IS defined: (ClipStringH is ignored.)
    • ClipStringW IS defined:
    Text wraps to the next line only if ClipStringW is reached. Text is clipped if H is reached.
    The width of the meter is the length of the string or ClipStringW, whichever is shorter.
    The height of the meter is the defined H value.
    • W IS defined: (ClipStringW is ignored.)
    • H IS defined: (ClipStringH is ignored.)
    Text wraps to the next line only if W is reached. Text is clipped if H is reached.
    The width and height of the meter will be the defined W and H.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Changes to ClipString

Post by jsmorley »

Here is a skin that demonstrates a way you can use ClipString=2 to have a more dynamic display of strings of unknown / variable length.
BreakingNews_2.1.rmskin
(50.23 KiB) Downloaded 1020 times
01.jpg
02.jpg
User avatar
moshi
Posts: 1740
Joined: November 13th, 2012, 9:53 pm

Re: Changes to ClipString

Post by moshi »

very, very nice. thanks a lot :)

actually there was a glitch in the older versions. if you used:

Code: Select all

[MeterText]
Meter=String
W=100
H=[MeterText:H]
ClipString=1
it displayed the whole text at a fixed width. the calculated height was 0 though.

now this means a lot of work for me.
User avatar
~Faradey~
Posts: 366
Joined: November 12th, 2009, 4:47 pm
Location: Ukraine

Re: Changes to ClipString

Post by ~Faradey~ »

OMG! :o :rofl:
i've spent two days on figuring and writing lua script to do "same" clipping of text, and you've added it natively...well, i'm really happy to see that now it's a native option...i didn't test it though, but i'm sure it's works flawlessly.

Thank you.

i've already mentioned this (way back earlier), but i wish you would have a some kind of list of future ideas and other stuff what's being planned on future, so people could know ;(... but it's no biggie...
User avatar
moshi
Posts: 1740
Joined: November 13th, 2012, 9:53 pm

Re: Changes to ClipString

Post by moshi »

okay, tried it. works great.

but: unfortunately i found a glitch in Rainmeter in how it calculates the height of string meters. it seems Rainmeter is not using the actual height of a line of text, but a rounded value. and so the amount of space under the last line gets bigger and bigger the more lines you have.

hardly noticeable with a few lines, but have a look here:
Untitled-1.jpg
User avatar
moshi
Posts: 1740
Joined: November 13th, 2012, 9:53 pm

Re: Changes to ClipString

Post by moshi »

an other thing i noticed:
a #CRLF# seems to add two additional empty lines to a a string.
User avatar
Brian
Developer
Posts: 2673
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: Changes to ClipString

Post by Brian »

moshi wrote:but: unfortunately i found a glitch in Rainmeter in how it calculates the height of string meters. it seems Rainmeter is not using the actual height of a line of text, but a rounded value. and so the amount of space under the last line gets bigger and bigger the more lines you have.
We aren't actually calculating any measurements, it is the Windows API (GDI+) that is doing it, however we may have to tweak it a little. So far, it is hard to determine if the extra pixel is a rounding "error" or just font metrics. I am not positive as to what is causing this, but I will dig deeper into this.

moshi wrote:an other thing i noticed:
a #CRLF# seems to add two additional empty lines to a a string.
Thank you for reporting, I can confirm the behavior. Expect a fix by next week.

-Brian
User avatar
moshi
Posts: 1740
Joined: November 13th, 2012, 9:53 pm

Re: Changes to ClipString

Post by moshi »

just saw something else with #CRLF#:

if there are two lines before #CRLF# it seems to add four additional lines.

edit: it seem to be the number of lines after the #CRLF# that influence this.
User avatar
Brian
Developer
Posts: 2673
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: Changes to ClipString

Post by Brian »

I believe all the issues (and a few others I found) have been fixed for the next beta.

Thanks again for all the testing! It was a little complicated figuring out ever "scenario".

BTW - I updated the first post in this thread with a some changes for the next beta.

-Brian
User avatar
moshi
Posts: 1740
Joined: November 13th, 2012, 9:53 pm

Re: Changes to ClipString

Post by moshi »

i tried the sneak peek.

first of all: great, i can definately live with it, and this new ClipString=2 feature is something that makes my favorite skin so much better.

now the nitpicky part (which you probably should ignore, as it is really almost invisible):
the metrics part is not really fixed, but the Meter:H/number-of-lines ratio is wrong the other way round now.
i did compare the height of the Meter with changing numbers of lines:

Code: Select all

line number    height      ratio
1	20	20
2	38	19
3  	57  	19
4	75	18.75
11 	204 	18.545
23 	425 	18.478
32	591	18.468
the real line height is something like 18.428 (this is only guessed).

the graph looks something like this:
chart.png
i have forgotten all my math, but at least this probably means the calculated meter height will never be smaller than the actual height of text actually displayed.
with a really large amount of lines, the last line might look like this:
Untitled-1.jpg
can't test this though (lack of screen)

but again, just ignore that. i love it how it is now. ;)
Post Reply