Thread for help with the Shape meter

[Yincognito]

A work of art indeed. But an attached skin would have been nice.

Thanks - I thought that being a single file, providing the packed skin wouldn't be necessary, but here you go:

QuadProgress_1.0.0.rmskin

The bars should look like this [...] And the measure should be like this:

Just some minor notes, if permitted:
- are two bars necessary instead of just one (since the inverse of the measure will be the part of the frame that's not covered by the plain measure progress)?
- as far as I know (correct me if I'm wrong) FreeDiskSpace already / automatically holds both the value and the total for the desired drive, so your last 2 measures aren't really needed, since you can simply do [MeasureFreeDiskSpaceRaw:%] and similar, and then multiplying with the appropriate coordinate difference in the meters (could need a division by 100 though, can't remember whether those percentual values are in the 0..1 or 0..100 range).

Unless ofc you want to follow the path of Arch Linux and let the user build it on their own.

Well, I already built the whole shape for them here, you want me to build them the skin as well? Maybe even feed them and put them in bed?

[CodeCode]

This time complying to yincognito I won't be handing over the solution since it won't help you in the long run. Tho I will tell you how to.

Take an existing bar. Right to left or left to right. If the bar is Right to left(which most probably is the case) make two dynamic shapes in the same section, one going from right to left that is the used disk space. And one from left to right, showing the free disk space. And vice versa for left to right. The bars should look like this:

Screenshot 2021-06-12 221451.png

And the measure should be like this:

Code: Select all

[MeasureFreeDiskSpaceRaw]
Measure=FreeDiskSpace
Drive=C:
UpdateDivider=60

[MeasureUsedDiskSpaceRaw]
Measure=FreeDiskSpace
Drive=C:
InvertMeasure=1
UpdateDivider=60

[MeasureTotalDiskSpace]
Measure=FreeDiskSpace
Drive=C:
UpdateDivider=-1
Total=1

[MeasureFreeDiskSpace]
Measure=Calc
Formula=(MeasureFreeDiskSpaceRaw/MeasureTotalDiskSpace)*100
UpdateDivider=60

[MeasureUsedDiskSpace]
Measure=Calc
Formula=(MeasureUsedDiskSpaceRaw/MeasureTotalDiskSpace)*100
UpdateDivider=60

Thanks once and again death.crafter. Your programming knowledge, and the time you take to share it is truly invaluable to me. I guess that Virgos are indeed birds of a feather, if not just enjoying coding in general.

[CodeCode]

Thanks - I thought that being a single file, providing the packed skin wouldn't be necessary, but here you go:
QuadProgress_1.0.0.rmskin


Just some minor notes, if permitted:
- are two bars necessary instead of just one (since the inverse of the measure will be the part of the frame that's not covered by the plain measure progress)?
- as far as I know (correct me if I'm wrong) FreeDiskSpace already / automatically holds both the value and the total for the desired drive, so your last 2 measures aren't really needed, since you can simply do [MeasureFreeDiskSpaceRaw:%] and similar, and then multiplying with the appropriate coordinate difference in the meters (could need a division by 100 though, can't remember whether those percentual values are in the 0..1 or 0..100 range).


Well, I already built the whole shape for them here, you want me to build them the skin as well? Maybe even feed them and put them in bed?

Due to the transparencies, of the bars, the overlap on the right side caused everything to glow either green or yellow depending on the order of the overlapping shapes.

Because the shapes are not truly bar measures, the calcs are certainly needed to give both opposing shapes a place to be at the right time - if I get what is going on there, that is.

[Yincognito]

Due to the transparencies, of the bars, the overlap on the right side caused everything to glow either green or yellow depending on the order of the overlapping shapes.

I see - sorry, I wasn't aware of the specifics in your code. So, were the 2 "bars" necessary or not?

Because the shapes are not truly bar measures, the calcs are certainly needed to give both opposing shapes a place to be at the right time - if I get what is going on there, that is.

Yes, you got it, but this (i.e. FreeDiskSpace measure's percentual value) has nothing to do with whether the meter is a bar or not. For example, using my automated skin above and editing the [Progress] measure, this is what I get, in my case (28 GB free out of 100 GB on C):

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1

[Progress]
Measure=FreeDiskSpace
Drive=C:
Label=1
UpdateDivider=5
;InvertMeasure=1

[ProgressBar]
Meter=Shape
Shape=Path FramePath | Fill Color 0,0,0,128 | StrokeWidth 2 | StrokeColor 255,255,255,255
FramePath=20,0 | LineTo 0,70 | LineTo 275,45 | LineTo 270,30 | ClosePath 1
Shape2=Path ProgressPath | Fill Color 0,255,0,128 | StrokeWidth 2 | StrokeColor 255,0,0,255
ProgressPath=20,0 | LineTo 0,70 | LineTo (0+275*[Progress:%]/100),(70-25*[Progress:%]/100) | LineTo (20+250*[Progress:%]/100),(0+30*[Progress:%]/100) | ClosePath 1
DynamicVariables=1

FreeDiskSpace Percentual.jpg

So, apart from those glow considerations you mention, it easily works - without the shape meter being a bar or anything, without any additional Calc measures.

[death.crafter]

Just some minor notes, if permitted:
- are two bars necessary instead of just one (since the inverse of the measure will be the part of the frame that's not covered by the plain measure progress)?
- as far as I know (correct me if I'm wrong) FreeDiskSpace already / automatically holds both the value and the total for the desired drive, so your last 2 measures aren't really needed, since you can simply do [MeasureFreeDiskSpaceRaw:%] and similar, and then multiplying with the appropriate coordinate difference in the meters (could need a division by 100 though, can't remember whether those percentual values are in the 0..1 or 0..100 range).

Ohh I see. I don't use these measures much cause I don't like a cluttered desktop(I only have a visualizer which is WIP lol). But thanks for letting me know.

Well, I already built the whole shape for them here, you want me to build them the skin as well? Maybe even feed them and put them in bed?

Lmao. But if you join our Discord server and see the #help channel, you'd better hand over a skin after fixing it rather than explaining them how to do it.

[balala]

New puzzle.
Using InvertMeasure to have yellow progress from right to left.

Hope I didn't misunderstand something, sorry if I did.
This is not why the InvertMeasure has been developed for. When setting the InvertMeasure=1 option on a measure, its value is "inverted". In this case for instance this means that the value returned by the [MeasureGPUTemp2] measure is not waring between 0 (StartValue) and 100 (EndValue), but exactly oposite, from 100 to 0. The meter (in this case a Shape meter) shows accordingly this variation.
To get what you want, you probably have to rewrite the TopFrame option of the [ProgBarRTA] meter. For instance something like this: TopFrame=265, 80 | LineTo 275,132 | LineTo (5+270*(100-[MeasureGPUTemp2])/100),(149-17*(100-[MeasureGPUTemp2])/100) | LineTo (265*(100-[MeasureGPUTemp2])/100),(125-45*(100-[MeasureGPUTemp2])/100) | ClosePath 1 (and remove the InvertMeasure=1 option from the [MeasureGPUTemp2] measure).

[death.crafter]

Due to the transparencies, of the bars, the overlap on the right side caused everything to glow either green or yellow depending on the order of the overlapping shapes.

Because the shapes are not truly bar measures, the calcs are certainly needed to give both opposing shapes a place to be at the right time - if I get what is going on there, that is.

Actually yincognito is right here. Instead of calc you can use [MeasureUsedDiskSpaceRaw:%]/100 and (1-[MeasureUsedDiskSpace:%]/100) instead of four different measures.

[death.crafter]

Hope I didn't misunderstand something, sorry if I did.
This is not why the InvertMeasure has been developed for. When setting the InvertMeasure=1 option on a measure, its value is "inverted". In this case for instance this means that the value returned by the [MeasureGPUTemp2] measure is not waring between 0 (StartValue) and 100 (EndValue), but exactly oposite, from 100 to 0. The meter (in this case a Shape meter) shows accordingly this variation.
To get what you want, you probably have to rewrite the TopFrame option of the [ProgBarRTA] meter. For instance something like this: TopFrame=265, 80 | LineTo 275,132 | LineTo (5+270*(100-[MeasureGPUTemp2])/100),(149-17*(100-[MeasureGPUTemp2])/100) | LineTo (265*(100-[MeasureGPUTemp2])/100),(125-45*(100-[MeasureGPUTemp2])/100) | ClosePath 1 (and remove the InvertMeasure=1 option from the [MeasureGPUTemp2] measure).

Umm... I don't know how temperatures are converted to percentual values but I think formulas should be (1-[MeasureGPUTemp2]/100).

[Yincognito]

Ohh I see. I don't use these measures much cause I don't like a cluttered desktop(I only have a visualizer which is WIP lol). But thanks for letting me know.

Yeah, as a matter of fact, you can ALWAYS use [Progress:%] in the shape's formula, assuming the [Progress] measure is either a CPU, FreeDiskSpace, Memory or Loop measure, or, if not, that the measure has a MinValue and MaxValue set.

Lmao. But if you join our Discord server and see the #help channel, you'd better hand over a skin after fixing it rather than explaining them how to do it.

LMAO. They like thing handed on a plate for them, don't they?

Hope I didn't misunderstand something, sorry if I did.

No, you didn't. In his case, just two FreeDiskSpace measures, one with InvertMeasure=1 and one without, coupled with using [NameOfHisMeasure:%] in the meter's formulas would suffice.

[balala]

Umm... I don't know how temperatures are converted to percentual values but I think formulas should be (1-[MeasureGPUTemp2]/100).

According to the rules of math, the above formula is the same as what did I propose ((100-[MeasureGPUTemp2])/100)).