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.
It is currently May 6th, 2024, 2:49 am
formatting this skin shape and text - somewhat confusing [outcome achieved]
-
- Posts: 943
- Joined: May 7th, 2016, 7:32 am
Re: formatting this skin shape and text - somewhat confusing
My DevArt Gallery
There are many ways to be different - there is only one way to be yourself - be amazing at it
The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.
There are many ways to be different - there is only one way to be yourself - be amazing at it
The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.
-
- Developer
- Posts: 22631
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: formatting this skin shape and text - somewhat confusing
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
You do not have the required permissions to view the files attached to this post.
-
- Posts: 943
- Joined: May 7th, 2016, 7:32 am
Re: formatting this skin shape and text - somewhat confusing
That's cool.jsmorley wrote: ↑December 6th, 2019, 4:25 pmCode: 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
My DevArt Gallery
There are many ways to be different - there is only one way to be yourself - be amazing at it
The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.
There are many ways to be different - there is only one way to be yourself - be amazing at it
The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.
-
- Posts: 134
- Joined: June 30th, 2014, 8:44 am
Re: formatting this skin shape and text - somewhat confusing
Oh hey it's my skin. It's a C, not a K btw.
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.
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.
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.
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.
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.
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.
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.
-
- Developer
- Posts: 22631
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: formatting this skin shape and text - somewhat confusing
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.
-
- Developer
- Posts: 22631
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: formatting this skin shape and text - somewhat confusing
Here is my point on Padding in this context...
If you have this skin:
You get this:
If you indent the String meter 100 pixels, or for that matter 1000 pixles:
You get... uhm... this:
If you use padding:
You get this:
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.
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
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
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:
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.
You do not have the required permissions to view the files attached to this post.
-
- Posts: 134
- Joined: June 30th, 2014, 8:44 am
Re: formatting this skin shape and text - somewhat confusing
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.
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.
-
- Developer
- Posts: 22631
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: formatting this skin shape and text - somewhat confusing
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.
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.
-
- Rainmeter Sage
- Posts: 16200
- Joined: October 11th, 2010, 6:27 pm
- Location: Gheorgheni, Romania
Re: formatting this skin shape and text - somewhat confusing
I'm glad if not me is the only who is bothered by such things.