[BUG?] InlineSetting=Shadow doesn't render in Container

[Yincognito]

So, I've tried that. I set the Container meter to 0,0, shifted the path coordinates, then set the x and y values on the contained meter to absolute values that match where the path is being drawn. Here's the code:

Code: Select all

[MeterShadowStyle]
InlineSetting=Shadow | 2 | 2 | 3 | FF00FFFF

[ContainerShapeCurrentTemp]
Meter=Shape
H=120
W=120
X=0
Y=0
ThisPath= 150,10 | LineTo 150,90 | LineTo 270,50 | LineTo 270,10 | ClosePath 1
Shape=Path ThisPath | FillColor FFFF0099 | StrokeWidth 0

[MeterCurrentTemp]
Meter=String
;MeasureName=@CurrentTemperature
Text=18
MeterStyle=MeterShadowStyle
StringAlign=LeftTop
FontFace=Open Sans Light
FontSize=64
FontColor=FFFFFFFF
FontWeight=600
InlineSetting2=CharacterSpacing | 0 | -4
X=150
Y=-15
H=120
W=120
AntiAlias=1
;Container=ContainerShapeCurrentTemp

[ContainerShapeForecast]
Meter=Shape
H=120
W=120
X=0
Y=0
ThisPath= 150,90 | LineTo 150,130 | LineTo 270,130 | LineTo 270,50 | ClosePath 1
Shape=Path ThisPath | Fill Color 00FFFF99 | StrokeWidth 0

[MeterTodayForecast]
Meter=String
MeterStyle=MeterShadowStyle
Text=20
StringAlign=RightBottom
FontFace=Open Sans Light
FontSize=64
FontColor=FFFFFF
FontWeight=600
InlineSetting2=CharacterSpacing | 0 | -4
X=260
Y=160
W=120
H=120
AntiAlias=1
;Container=ContainerShapeForecast

Everything lines up nice and dandy, however, as soon as I uncomment the Container key, my text vanishes. I assume it's somewhere, just not where it needs to be to be visible within the container mask. I understand its positioning has now changed to being relative to the Container meter, but that one is at 0,0 so nothing should have changed. I tried playing with all sorts of values on the x and y values for the contained meter, nada. Admittedly, I can't entirely wrap my head around rainmeter's positioning logic, especially when it comes to strings that have their StringAlign value set to anything other than LeftTop (e.g. using CenterCenter needs the X shifted to half the width of the meter, but following meters now appear to base the relative positioning (nr, nR) on where ever the actual string's beginning and end is, regardless of the string meter's X or W values are ).
So while I believe you when you say this fixes my shadow issue, I'm still stuck because I have no clue where the hell my string meters are

LOL - your meters and positioning are just fine, relax. It's just that you forgot a small detail when copy pasting or modifying the existing code: the container width and height are not 120 by 120 anymore, they're bigger now since the container meter includes the "empty space" between the (0,0) origin and the top and left side of the container shape. In fact, I'm not even bothering to calculate (although it's quite easy, since it's all about the shape's right and bottom "edges", after all) and just removed them entirely and voila:

Code: Select all

[Variables]

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

---Styles---

[MeterShadowStyle]
InlineSetting=Shadow | 2 | 2 | 3 | FF00FFFF

---Meters---

[ContainerShapeCurrentTemp]
Meter=Shape
X=0
Y=0
ThisPath= 150,10 | LineTo 150,90 | LineTo 270,50 | LineTo 270,10 | ClosePath 1
Shape=Path ThisPath | FillColor FFFF0099 | StrokeWidth 0

[MeterCurrentTemp]
Meter=String
;MeasureName=@CurrentTemperature
Text="18"
MeterStyle=MeterShadowStyle
StringAlign=LeftTop
FontFace=Open Sans Light
FontSize=64
FontColor=FFFFFFFF
FontWeight=600
InlineSetting2=CharacterSpacing | 0 | -4
X=150
Y=-15
H=120
W=120
AntiAlias=1
Container=ContainerShapeCurrentTemp

[ContainerShapeForecast]
Meter=Shape
X=0
Y=0
ThisPath= 150,90 | LineTo 150,130 | LineTo 270,130 | LineTo 270,50 | ClosePath 1
Shape=Path ThisPath | Fill Color 00FFFF99 | StrokeWidth 0

[MeterTodayForecast]
Meter=String
MeterStyle=MeterShadowStyle
Text="20"
StringAlign=RightBottom
FontFace=Open Sans Light
FontSize=64
FontColor=FFFFFF
FontWeight=600
InlineSetting2=CharacterSpacing | 0 | -4
X=260
Y=160
W=120
H=120
AntiAlias=1
Container=ContainerShapeForecast

Shadow Test.jpg

The StringAlign influence on positioning is quite easy to understand, really. If it's Left then 0r is the left edge, if it's Center then 0r is in the middle, if it's right then 0r is the right edge - I'm talking about simple horizontal alignment. Don't use 0R relative to a right aligned string, as it won't be where you think it would be - use 0r as a base instead, as that will always be the right edge / side of the preceding meter, when that meter is a right aligned string. Of course, you can use the 0R as well, but only after understanding how this stuff works. Even so, I would still prefer to use 0r as a base for right alignement, if not for anything, at least because it's much more logical (0R on right aligned strings will be the right edge + the width of the meter, even if that meter is spanning "towards the left" in a right alignment scenario and in theory it should be the right edge - the width of the meter). By the way, the relative coordinates to a centered string will exhibit the same approach on coordinates for 0R, so again, use 0r (actually, base your positioning formulas on the r variant of relative positioning instead of the R one) and you'll be just fine.

[OnyxBlack]

LOL - your meters and positioning are just fine, relax. It's just that you forgot a small detail when copy pasting or modifying the existing code: the container width and height are not 120 by 120 anymore, they're bigger now since the container meter includes the "empty space" between the (0,0) origin and the left side of the container shape.

Woohoo, it works! Thanks for pointing that out, kinda obvious when you think about it (I used explicit W and H values so I can see at a glance where stuff needs to go, e.g. when calculating Path coordinates)

The StringAlign influence on positioning is quite easy to understand, really.

Well, only when you have it explained like that, then sure, it makes sense. Maybe the docs should be updated with a description like yours *wink*
Until then I'll just stick with my trusted trial&error approach

[Yincognito]

Woohoo, it works! Thanks for pointing that out, kinda obvious when you think about it (I used explicit W and H values so I can see at a glance where stuff needs to go, e.g. when calculating Path coordinates)

Well, only when you have it explained like that, then sure, it makes sense. Maybe the docs should be updated with a description like yours *wink*
Until then I'll just stick with my trusted trial&error approach

Glad you're happy with it. And the docs do have a description similar to mine, it's just that they don't mention the way 0R values are computed for centered or right aligned strings. Believe it or not, I too discovered this interesting (though a bit strange) way of computing the R values by trial and error.

[jsmorley]

Glad you're happy with it. And the docs do have a description similar to mine, it's just that they don't mention the way 0R values are computed for centered or right aligned strings. Believe it or not, I too discovered this interesting (though a bit strange) way of computing the R values by trial and error.

If someone wants to provide a clear, understandable description of this behavior that they think should be added to the documentation, that would be great.

[Yincognito]

If someone wants to provide a clear, understandable description of this behavior that they think should be added to the documentation, that would be great.

I'll think about it, since as you say, the description should be phrased in a more "professional" way. But really, there's not much to add other than the fact that the R positioning is computed by adding the whole width of the base meter to the anchor coordinates, even when from a visual point of view the corresponding width (which may or may not be the whole width, i.e. for centered meters) should be subtracted (e.g. in the case of center and right alignment of the base meter):

-------------
R COMPUTING BASED ON RIGHT ALIGNMENT (base anchor point: the right edge of the red meter):

Code: Select all

[Variables]

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

---Meters---

[MeterCurrentTemp]
Meter=String
X=100
StringAlign=Right
FontFace=Open Sans Light
FontSize=64
FontColor=FFFFFFFF
FontWeight=600
SolidColor=255,0,0,255
AntiAlias=1
Text="H"

[MeterTodayForecast]
Meter=String
X=0R
StringAlign=Left
FontFace=Open Sans Light
FontSize=64
FontColor=FFFFFFFF
FontWeight=600
SolidColor=0,0,255,255
AntiAlias=1
Text="H"

R Positioning To A Right Aligned Meter.jpg

-------------
R COMPUTING BASED ON CENTER ALIGNMENT (base anchor point: the horizontal middle of the red meter):

Code: Select all

[Variables]

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

---Meters---

[MeterCurrentTemp]
Meter=String
X=100
StringAlign=Center
FontFace=Open Sans Light
FontSize=64
FontColor=FFFFFFFF
FontWeight=600
SolidColor=255,0,0,255
AntiAlias=1
Text="H"

[MeterTodayForecast]
Meter=String
X=0R
StringAlign=Left
FontFace=Open Sans Light
FontSize=64
FontColor=FFFFFFFF
FontWeight=600
SolidColor=0,0,255,255
AntiAlias=1
Text="H"

R Positioning To A Center Aligned Meter.jpg

This follows a similar approach for vertical or horizontal+vertical scenarios, as far as I know. The horizontal one is shown above for simplicity purposes.

So, in a nutshell, 0R = 0r + [BaseMeter:W] (horizontally) and 0R = 0r + [BaseMeter:H] (vertically), irrespective of the alignment in [BaseMeter] (which may logically imply a subtraction of the full or half the base meter size from 0r, in the case of right and center alignments).

[OnyxBlack]

If someone wants to provide a clear, understandable description of this behavior that they think should be added to the documentation, that would be great.

Wouldn't this best be done by a Dev with a clear understanding of the internal rules that govern this?
Speaking of Devs, any thoughts on the issue raised in the original post of this topic?

[balala]

So, in a nutshell, 0R = 0r + [BaseMeter:W] (horizontally) and 0R = 0r + [BaseMeter:H] (vertically),

Or:

• 0R=[BaseMeter:XW] (horizontally)
• 0R=[BaseMeter:YH] (vertically)

[Yincognito]

Or:

• 0R=[BaseMeter:XW] (horizontally)
• 0R=[BaseMeter:YH] (vertically)

False.

Proof - add:
- OnUpdateAction=[!Log "XW = [MeterCurrentTemp:XW]"] to [MeterCurrentTemp]
- OnUpdateAction=[!Log "X = [MeterTodayForecast:X]"] to [MeterTodayForecast]
in my sample code above (with the red and blue meters), optionally accompanied by UpdateDivider=-1 and DynamicVariables=1 (although they're not really needed in this case), and you'll see that the XW of the base meter is not equal to the 0R of a relatively positioned subsequent meter, for other alignments than left/top.

This is actually hinted at by the notes below the XW and YH options in the manual (and also the italic text there, which talks about the "end" of the meter):

This uses the "real" X/Y/W/H values. [...] The values for X or Y may be different than the values in the meter options if StringAlign is used on a String meter.

I do agree though that the note isn't that obvious in its implications.

P.S. Point is, the "end" of the meter will only be the 0R of another subsequent relatively positioned meter if the alignment in the former is left/top. For the rest of the cases, the horizontal 0R and vertical 0R will be different from [BaseMeter:XW] and [BaseMeter:YH], respectively. Obviously, the XW and YH values are the correct ones.

[balala]

the XW of the base meter is not equal to the 0R of a relatively positioned subsequent meter, for other alignments than left/top.

I didn't follow too closely the whole topic, just supposed the are aligned this way, especially that this is the default alignment. Sorry if they are not.

[Yincognito]

I didn't follow too closely the whole topic, just supposed the are aligned this way, especially that this is the default alignment. Sorry if they are not.

Yeah, no worries. My guess is that the 0R relative positioning initially assumed a top left alignment of the base meter, hence its "modus operandi", and then when it came to the center and right alignments and the other variations, it was too late to change how 0R is computed without breaking backward compatibilty in a lot of skins, so it stayed that way, with the XW and YH parameters somewhat compensating this by offering the real thing.

Or, it can be some other internal reason I'm not aware of. It's not such a big deal though, since there are at least 2 workarounds:
- use the r relative positioning instead of the R one as a base for calculations, to avoid confusion
- use the XW and YH parameters of the base meter section variable

I only mentioned this aspect because OnyxBlack was talking about the difficulty of proper wrap his head around the center / right relative positioning, and thought it was worth mentioning this slight "difference" from what would be a logically / visually proper way of computing the R positioning.