formatting this skin shape and text - somewhat confusing [outcome achieved]

[Mor3bane]

oh, sorry - I meant that the right side was correct, and the opposite would be the same on the left.

But, that is helpful to know just the same.

[jsmorley]

Code: Select all

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

[Variables]

[MeterShape]
Meter=Shape
Shape=Rectangle 0,0,180,100 | StrokeWidth 0
Shape2=Rectangle 20,0,180,100,20 | StrokeWidth 0
Shape3=Ellipse 50,50,25 | StrokeWidth 0
Shape4=Combine Shape | Union Shape2 | Exclude Shape3

1.png

[Mor3bane]

Code: Select all

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

[Variables]

[MeterShape]
Meter=Shape
Shape=Rectangle 0,0,180,100 | StrokeWidth 0
Shape2=Rectangle 20,0,180,100,20 | StrokeWidth 0
Shape3=Ellipse 50,50,25 | StrokeWidth 0
Shape4=Combine Shape | Union Shape2 | Exclude Shape3

1.png

That's cool.

[Yamajac]

Oh hey it's my skin. It's a C, not a K btw.

You are going to want to use Padding for that.

No, the text meter has an X value of 5 to be slightly indented already, and you'd just increase that if you want it indented more. Padding serves the same purpose but since I've already used an X value, it's important to be aware of it and change that or modify BOTH the x value and padding, so as not to cause confusion later when you wonder why things don't line up like how you'd expect.

P.S. I hate white space in options...

Nowhitespace=ugly,unreadablecode:D

Rainmeter doesn't *usually* care about whitespace, so I like making my code easily readable. It's nice being able to see a clear divide between the options and the values when I'm looking for a specific option/value.

jsmorely

what do you reckin this is likely to achieve, and/or is it actually necessary - or is it recursion just for the sake of it?

I use a [NoUpdate] measure at the bottom of almost all of my skins to enable previous measures/meters that don't need to be updated when the skin first loads. You can use OnRefreshAction = [!UpdateMeasureGroup NoUpdate] instead if you want, but putting a measure at the bottom of the skin makes it easier to see what's happening, IMO. With the [Rainmeter] section, it would seem as though the bangs would get processed first, even though they don't. Whereas with the measure at the bottom, it's clear that the bangs are run after all the other measures, since it's just literally after those measures.

Never mind - found the cause.

An X= value was set to 5 when should be 0.

No, it wasn't set to 5 when it should be 0. It was set to 5 when it should be 5, because I wanted the text indented 5 pixels.



Anyway, looks nice. Glad somebody other than me's getting some use out of my skin. Most of my skins don't often see use because of how unorthodox they are lol.

[jsmorley]

I fully stand by every word I said in my post about this skin. You absolutely need Padding in this context if you want to indent a meter INSIDE a container, white space in Key=Value pairs just looks like an affectation and is not consistent with the INI format, and there is literally no point in a whole extra measure at the bottom of a skin to replace one line in [Rainmeter]. Those last two are just my opinion of course, and if we all liked the same things, there would be a hell of a traffic jam.

[jsmorley]

Here is my point on Padding in this context...

If you have this skin:

Code: Select all

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

[Variables]

[MeterContainer]
Meter=Shape
W=200
H=30
SolidColor=0,0,0,1

[MeterContent]
Meter=String
FontSize=13
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
AntiAlias=1
Text=Hello World

You get this:

1.png

If you indent the String meter 100 pixels, or for that matter 1000 pixles:

Code: Select all

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

[Variables]

[MeterContainer]
Meter=Shape
W=200
H=30
SolidColor=0,0,0,1

[MeterContent]
Meter=String
X=100
FontSize=13
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
AntiAlias=1
Text=Hello World

You get... uhm... this:

1.png

If you use padding:

Code: Select all

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

[Variables]

[MeterContainer]
Meter=Shape
W=200
H=30
SolidColor=0,0,0,1

[MeterContent]
Meter=String
FontSize=13
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text=Hello World

You get this:

2.png

It's important to remember that the "container" is NOT DRAWN. Only the "solid content" that is both contained within the boundaries of the container, and is positioned on a "solid" pixel of the container is drawn.

[Yamajac]

Padding and X will both solve the same problem, in slightly different ways.



The one on the right has padding = 10,0,0,0 and the one on the left has x = 10.


The only difference, functionally, between these two, even in the context of a container, is in the bounding box of the meter. Things like SolidColor will draw differently, because Padding adds to the width of the meter. You can see the one on the left has a few pixels of space between the scrollbar and the text's background. This is because the text meter starts at that point, instead of the text itself being offset within the meter.

The yellow bit is where the container lies. You can see that regardless of whether you use Padding or X, the meter will still be drawn correctly within the container. I chose to use an X value over padding because when I eventually make the scrollbar functional as a slider, I don't want the skins being directly next to the scrollbar making me misclick and refresh skins when I just want to scroll through the list.

Now, you could argue that I could make the container smaller and move it to match where the text actually gets drawn. This would require math, and I didn't really want to, so I didn't. But this would be a valid argument that you could make.

If you would prefer to use padding and don't mind the misclicks, that's also OK. This is a subjective point, but it's still important to recognize how and why it was done differently before, so you can make the adjustment properly and understand what that adjustment actually means, and the implications of doing so.

The other points are subjective. But padding isn't a magical fix to all problems with containers. Containers aren't black magic, they just disable drawing outside of their bounding box. There isn't a correct way to draw something in a container, it depends on the circumstances. I SPECIFICALLY used an X value BECAUSE it caused functioned differently. I don't very much appreciate you saying this decision was objectively wrong just because it looks better to you a different way. What gives you the right to be an arbitrator of skin design?

Please understand what you're talking about next time you talk about opinions as fact. Or at the very least, don't be so condescending about it and accept that you can be wrong too. Padding vs X here is nothing more than an aesthetic difference, and you should treat it as such, with neither being objectively superior.

[jsmorley]

Let's not get all butt-hurt over this shall we? My only point was that you CAN'T use X on a meter to position a meter, in and of itself, in the context of a container. The amount of X that you indent the meter is not going to be drawn in the container. It won't be "solid". You can certainly use X to position a meter in the context of the skin, or in the context of another meter that is acting as a background.

All my comments were about the example code that Mor3bane posted. I don't know what would or wouldn't work best in any other skin code.

Since in that example code there was simply one completely invisible "container" and one "content" meter that was depending entirely on SolidColor to create a background, only Padding helps. X accomplishes nothing.

In any case, I was not trying to be condescending or arrogant, and I can be, and often am, wrong. I'll just get out of this thread and leave it to you.

[balala]

P.S. I hate white space in options...

No:
X = 10

Yes:
X=10

I'm glad if not me is the only who is bothered by such things.