Dynamic bg (shape) size

[eclectic-tech]

yes, but it would call for determination of the height of all the meters, and it isn't always easy. Especially if we have images, shapes... Right?

Well you are in control of all the meters, so you should be able to design them to have fix heights, depending on the content, and easily determine the overall size, right?

I read a bit about the containers but haven't used it in the practice as yet. But have to ask you a question of it. So, "Hidden=1" sets a meter's W and H to 0 but X and Y haven't been touched. How it works with the "Container" option set in the Meter?

The container meter controls what is visible. You would not have to hide/show meters or calculate positions, simply change the container meter; it would act as a "View port" only showing the portion of the skin you want visible.
You should be able to design a skin of any size or shape and control what is visible by changing the W & H of the container meter.
However, if you are re-arranging the content, then you would need to consider the initial placement of the contents and see if a "view port" would work.

Container meters are a powerful and simple solution for some situations that, prior to it's creation, required lots of calculations to achieve, but they may not suit your design...

The final solution is always up to you; most skins (besides visualizers) will generally not affect performance levels.

Always happy to bounce ideas around!

[pul53dr1v3r]

Thx for the detailed answer js. Was mostly interested in what's going on with the "flush" when we hide a container controlled meter, and is there a need to move the meter's Y position in order to be able to snap rest of the skin to the desktop edge.

Well you are in control of all the meters, so you should be able to design them to have fix heights, depending on the content, and easily determine the overall size, right?

Yes, but sometimes i don't really need to determine the height. For instance, when using glyphs. Also, theirs font sizes usually has nothing to do with regular font sizes. The difference if pretty big. But thx for that of your suggestions. Worth considering.

Container meters are a powerful and simple solution for some situations that, prior to it's creation, required lots of calculations to achieve, but they may not suit your design...

Will see...

The final solution is always up to you; most skins (besides visualizers) will generally not affect performance levels.

just noticed that some of container examples from the link affect performance as well, but believe it must be so.

[jsmorley]

Thx for the detailed answer js. Was mostly interested in what's going on with the "flush" when we hide a container controlled meter, and is there a need to move the meter's Y position in order to be able to snap rest of the skin to the desktop edge.

The container meter will define the overall size of things. The content meters play no role in that, as only the parts of them that are inside the W and H of the container exist at all. Any part of a content meter that extends outside its container is just truncated.

Code: Select all

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

[MeterContainer]
Meter=Shape
Shape=Rectangle 0,0,100,100 | StrokeWidth 0

[MeterBox]
Meter=Image
X=25
Y=25
W=100
H=100
SolidColor=255,0,0,255
Container=MeterContainer

1.png

I used CTRL-ALT-Click to "group select" this skin, and so you can see that the skin size is defined by the 100X100 of the container meter, with the right and bottom of the content meter that extends outside of the container just not existing... Doesn't make a bit of difference if the bit of the content that is outside the container is defined as solid or transparent, visible or hidden. It's just not drawn.

If I make the content meter smaller, you can see that the overall size is still defined by the size of the container it is in.

Code: Select all

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

[MeterContainer]
Meter=Shape
Shape=Rectangle 0,0,100,100 | StrokeWidth 0

[MeterBox]
Meter=Image
X=25
Y=25
W=25
H=25
SolidColor=255,0,0,255
Container=MeterContainer

2.png

Even if the only content meter in a container is "hidden", the result will be an entirely content-less invisible container that still has the W and H size of the container meter for purposes of relative positioning, snap to edges, or keep on screen.

Code: Select all

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

[MeterContainer]
Meter=Shape
Shape=Rectangle 0,0,100,100 | StrokeWidth 0

[MeterBox]
Meter=Image
X=25
Y=25
W=25
H=25
SolidColor=255,0,0,255
Container=MeterContainer
Hidden=1

[MeterString]
Meter=String
Y=R
FontSize=11
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text=I'm relative

3.png

The way I think of this is that when you have a content meter inside a container meter, a brand-new combined meter is created that consists of both, with the W and H size defined by the container and what is actually displayed defined by the content. This is why Container is so good. It simultaneously creates a "viewport" and a "mask".

[jsmorley]

just noticed that some of container examples from the link affect performance as well, but believe it must be so.

I don't believe the Container functionality has any appreciable effect on performance one way or the other. Now, it is certainly possible that one or more of those examples that do a lot of work with ActionTimer and animations might use some CPU, but that's a horse of a different color.

[pul53dr1v3r]

Very good examples for the start to understand it better, since the theory without the practice is in vain. Thx.

I don't believe the Container functionality has any appreciable effect on performance one way or the other. Now, it is certainly possible that one or more of those examples that do a lot of work with ActionTimer and animations might use some CPU, but that's a horse of a different color.

I thik so as well. Btw, probably the Weather skin examples are causing the highest CPU usage, but far away from the alarm. My CPU is a trash so it's more noticeable. But it's a real beauty what can be done with that feature.