Shape meter layers width behavior with [#CURRENTSECTION#:W] and non-fixed text width formula

[Crest]

After some troubleshooting I realized why [#CURRENTSECTION#:W] wasn't picking up the width of Shape layers for a shape meter, since it turned out in certain scenarios they don't affect the actual shape meter's width—only that particular shape layer's width itself.

This was a puzzling until I narrowed down what was occurring. At first I thought this was a bug or something with the GetW() Lua function which I was using when I first observed this. Maybe someone could comment on whether this is expected behavior or not.

Here's an example skin which demonstrates the behavior:

Code: Select all

[Variables]
Bg1=240,123,13
Bg2=73,165,211
Height=30

[Rainmeter]
AccurateText=1
DynamicWindowSize=1
Update=1000

[AreaText]
Meter=String
X=0
Y=0
; W=100
Text=This is a test
Antialias=1
ClipString=1

[Area]
Meter=Shape
X=0R
Y=0r
Shape=Rectangle 0,0,(500 - [#CURRENTSECTION#:X] - [#CURRENTSECTION#Text:W]),#Height#,0 | Fill Color #Bg1# | StrokeWidth 0
Shape2=Rectangle 0,(#Height# / 2),[#CURRENTSECTION#:W],(#Height# / 2),0 | Fill Color #Bg2# | StrokeWidth 0
DynamicVariables=1

Screenshot of the result:

Screenshots - First example.png

So we can see that with a non-fixed width text meter the first Shape doesn't affect the shape meter's width so when [#CURRENTSECTION#:W] is used for Shape2 the width isn't detected and instead the unaffected 500px width from Shape is used instead.

However in the above skin code if we uncomment the W=100 then it produces a more expected result with both shape layers having a matching width. This made me question whether the above was intended behavior or not, since I would assume the text meter's width would be detected whether it had a fixed width or not.

Screenshots - Second example.png

Finally if we instead add the same formula from Shape instead to the meters width (W) and use [#CURRENTSECTION#:W] for both shape layer widths we similarly get a more expected outcome:

Screenshots - Third example.png

Skin code with this latter change:

Code: Select all

[Variables]
Bg1=240,123,13
Bg2=73,165,211
Height=30

[Rainmeter]
AccurateText=1
DynamicWindowSize=1
Update=1000

[AreaText]
Meter=String
X=0
Y=0
Text=This is a test
Antialias=1
ClipString=1

[Area]
Meter=Shape
X=0R
Y=0r
W=(500 - [#CURRENTSECTION#:X] - [#CURRENTSECTION#Text:W])
Shape=Rectangle 0,0,([#CURRENTSECTION#:W]),#Height#,0 | Fill Color #Bg1# | StrokeWidth 0
Shape2=Rectangle 0,(#Height# / 2),[#CURRENTSECTION#:W],(#Height# / 2),0 | Fill Color #Bg2# | StrokeWidth 0
DynamicVariables=1

[Brian]

This is expected behavior, but it isn't super obvious.

First and foremost, a shape meter's width is not determined while Rainmeter is parsing its options. It is determined after all the shapes have been parsed.

But that isn't what is causing your issue.

What you are seeing is a consequence of meter initialization. This happens before the Update cycle begins, and its purpose is to calculate some "default" (I use this term very loosely) values in case section variables are used before they have any value.

So, during meter initialization, some values get populated. Values like X, Y, W, H (and others). A string meter can have a defined width, or the width can be determined by the string's size. For your first example, the string meter's width is 0 (since no W is defined). When the shape meter is processed, the Shape's width is determined by the formula (500 - [#CURRENTSECTION#:X] - [#CURRENTSECTION#Text:W]), at this point, the section variables evaluate to 0 since the current section has no width, and AreaText's width is also 0. So, (500 - 0 - 0) = 500. Shape2's width is defined by the current section's width, so it is also 0 at this point. Once all the shapes are done, the shape meter finds the largest width (which is the first shape) and sets as the meter width. So it is 500.

Then the Update cycle happens.

AreaText gets parsed again, and its width is now determined to be 75 (based on the string). Area then gets parsed, and Shape's width is determined to be (500 - 75 - 75), while Shape2's width is determined to be 500 (from the initialization). So, Area's width is still 500.


The second example works as expected since during initialization, the string meter AreaText width is set to 100. Likewise, the Area meter Shape width is determined to be (500 - 100 - 100).


I hope that shed's some light on this.

-Brian

PS - It's not really a good idea to mix regular variables and section variables. Use nested syntax instead.

[Crest]

Thanks for the detailed explanation. Thread will hopefully also be useful to those coming across something similar.

I'll just add some phrases that might help with others' queries: one shape is shorter/wider than the other, dynamic width calculations.