It is currently April 25th, 2024, 4:58 pm

[FEATURE] BevelType Color

Report bugs with the Rainmeter application and suggest features.
User avatar
Yincognito
Rainmeter Sage
Posts: 7164
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [FEATURE] BevelType Color

Post by Yincognito »

Brian wrote: February 15th, 2022, 5:52 am Rainmeter manually draws them. There are 8 lines to draw (2 for each edge), and their position depends on whether they are "skin" bevels, or "meter" bevels. Skin bevels draw "inside" or within the bounds of the skin. Meter bevels draw outside of the meter.

While I am sure adding a proper "width" to this is possible, I am not sure we are going to explore this too much, given all the manually drawing.

IMO, I think using a shape meter gives the most flexibility.

-Brian
You're right about flexibility, but you're not regarding usability, and I'll explain why. If you don't know the size of the skin (e.g. have DynamicWindowSize=1 in the [Rainmeter] section) and want to draw a beveled background, you'll have a serious problem knowing how big the shape should be, because you're only able to find it out AFTER every other meter in the skin has been drawn via the built in config dimensions variables. On the other hand, the background must be drawn BEFORE any other meter so as to not cover them and potentially rendering them invisible (if the background is solid). In other words, if you go via the classic method and place the background shape before the other meters, its size will only be updated properly after the first update, after all the meters are updated and the skin dimensions are known.

In my suite, I solved this conundrum by first drawing some invisibly colored meters (used as templates for the original ones) in order to be able to find out the skin dimensions, then drew the background using the previously acquired info, then drew the original meters. This technique, while a sort of a hack (or horribly complicated as jsmorley would say) does produce the desired effect, but is useless if you don't know beforehand how your skin would look like and how big it "should" be. So, you see, using the bevel option here is not about flexibility (which I agree that Shape meters offer), but about not having to resort to all sorts of intricated methods to achieve the desired effect of drawing a (dynamic or static, doesn't matter) bevel around an unknown sized skin. The latter is possible using the bevel option, but the bevel's thickness is not adjustable and looks a bit rudimentary on some resolutions.

P.S. I believe the above is true to some extent on the meter bevels as well.
P.S.S. Oh, and I also manually draw the variable width bevel, since I can't achieve it via an option, LOL. This is how I do it:

Code: Select all

[MT_Background]
Meter=Shape
Shape=Rectangle 0,0,#SkinWidth#,#SkinHeight# | StrokeWidth 0 | Fill LinearGradient SkinGradient
SkinGradient=#SkinGradientAngle# | #SkinSolidColor# ; 0.0 | #SkinSolidColor2# ; 1.0
Shape2=Path TopLeftBevel | StrokeWidth 0 | Stroke Color (255-((#SkinBevelType#-(#SkinBevelType#%2))/2)*255),(255-((#SkinBevelType#-(#SkinBevelType#%2))/2)*255),(255-((#SkinBevelType#-(#SkinBevelType#%2))/2)*255),255 | Fill Color (255-((#SkinBevelType#-(#SkinBevelType#%2))/2)*255),(255-((#SkinBevelType#-(#SkinBevelType#%2))/2)*255),(255-((#SkinBevelType#-(#SkinBevelType#%2))/2)*255),255
TopLeftBevel=0,0 | LineTo #SkinWidth#,0 | LineTo #SkinWidth#,#SkinBevelWidth# | LineTo #SkinBevelWidth#,#SkinBevelWidth# | LineTo #SkinBevelWidth#,#SkinHeight# | LineTo 0,#SkinHeight# | SetNoStroke 1 | ClosePath 1
Shape3=Path BottomRightBevel | StrokeWidth 0 | Stroke Color (255-(#SkinBevelType#%2)*255),(255-(#SkinBevelType#%2)*255),(255-(#SkinBevelType#%2)*255),255 | Fill Color (255-(#SkinBevelType#%2)*255),(255-(#SkinBevelType#%2)*255),(255-(#SkinBevelType#%2)*255),255
BottomRightBevel=0,#SkinHeight# | LineTo #SkinWidth#,#SkinHeight# | LineTo #SkinWidth#,0 | LineTo (#SkinWidth#-#SkinBevelWidth#),#SkinBevelWidth# | LineTo (#SkinWidth#-#SkinBevelWidth#),(#SkinHeight#-#SkinBevelWidth#) | LineTo #SkinBevelWidth#,(#SkinHeight#-#SkinBevelWidth#) | SetNoStroke 1 | ClosePath 1
UpdateDivider=-1
DynamicVariables=1
SkinBevelType is the equivalent of the BevelType option, so it can draw plain, sunken or raised bevels. Easy, huh? :sly:
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Active Colors
Moderator
Posts: 1254
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany

Re: [FEATURE] BevelType Color

Post by Active Colors »

Umm, bevels are good because they don't require to have extra meters in order to have a simple outline.
However, bevels support only squared corners. I wish there was something like bevel but for making outlines with custom rounded corners / corner radius without involving extra meters.
User avatar
Yincognito
Rainmeter Sage
Posts: 7164
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [FEATURE] BevelType Color

Post by Yincognito »

Active Colors wrote: February 15th, 2022, 2:25 pm Umm, bevels are good because they don't require to have extra meters in order to have a simple outline.
However, bevels support only squared corners. I wish there was something like bevel but for making outlines with custom rounded corners / corner radius without involving extra meters.
Honestly, I personally don't mind using Shape meters for that (whether it's variable thickness, round corners, or else), it's just that they need an extra update to know the dimensions of what they should draw when those amounts are dynamic, while bevels and BackgroundMode=2 or SolidColor variations seem to know in advance that info, which makes them ideal to draw the edges and the background of a meter or a skin. I wouldn't be interested so much in the features of the bevel option if not for that important detail... :confused:
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Active Colors
Moderator
Posts: 1254
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany

Re: [FEATURE] BevelType Color

Post by Active Colors »

Yincognito wrote: February 15th, 2022, 1:12 pm If you don't know the size of the skin (e.g. have DynamicWindowSize=1 in the [Rainmeter] section) and want to draw a beveled background, you'll have a serious problem knowing how big the shape should be, because you're only able to find it out AFTER every other meter in the skin has been drawn via the built in config dimensions variables. On the other hand, the background must be drawn BEFORE any other meter so as to not cover them and potentially rendering them invisible (if the background is solid). In other words, if you go via the classic method and place the background shape before the other meters, its size will only be updated properly after the first update, after all the meters are updated and the skin dimensions are known.
Can you give an example skin which demonstrates this problem? I might have a different solution to this conundrum.
User avatar
Yincognito
Rainmeter Sage
Posts: 7164
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [FEATURE] BevelType Color

Post by Yincognito »

Active Colors wrote: February 16th, 2022, 1:08 pm Can you give an example skin which demonstrates this problem? I might have a different solution to this conundrum.
There you go (instructions in the comments, make sure you toggle things from both comments to see all 4 variations: negative or positive update divider combined with bevel or shape modes):

Code: Select all

[Variables]
SC1=0,0,0
SC2=32,32,32
STC=255,0,0
SCA=128
STW=2
FSZ=16
Padding=0
Step=1

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

; Uncomment this and comment [Background] or comment this and uncomment [Background] to see the update differences between using a Bevel or a Shape skin outline

; BackgroundMode=2
; SolidColor=#SC1#,#SCA#
; SolidColor2=#SC2#,#SCA#
; GradientAngle=270
; BevelType=1
; BevelColor=#STC#,#SCA#
; BevelColor2=#STC#,#SCA#

; Set this to -1 to see the instant effect, set this to 1 to see the subsequent update effect

DefaultUpdateDivider=-1

---Meters---

[Background]
Meter=Shape
Shape=Rectangle (#STW#/2),(#STW#/2),(#CURRENTCONFIGWIDTH#-#STW#),(#CURRENTCONFIGHEIGHT#-#STW#) | Fill LinearGradient BackgroundGradient | StrokeWidth #STW# | Stroke Color #STC#,#SCA#
BackgroundGradient=90 | #SC1#,#SCA# ; 0.0 | #SC2#,#SCA# ; 1.0
DynamicVariables=1

[SomeMeter]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
FontSize=#FSZ#
AntiAlias=1
Padding=#Padding#,#Padding#,#Padding#,#Padding#
X=5
Y=5
Text="Something"
MouseScrollUpAction=[!SetVariable FSZ (Clamp(#FSZ#+#Step#,7,200))][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetVariable FSZ (Clamp(#FSZ#-#Step#,7,200))][!UpdateMeter *][!Redraw]
DynamicVariables=1
What happens is that the bottom and right edges are not drawn at the skin margins (or if they eventually do, it comes after a subsequent update) when scaling to a bigger text / skin, and they don't adapt to the new skin dimensions at all when scaling to a smaller text / skin, when using the Shape variant (though the latter might be something that I missed, not sure). Of course, when doing things via BackgroundMode=2 and Bevel=1, everything works perfectly, whether it's about scaling to bigger or to smaller...

I set the colors identical between the variants for better comparison. Pardon my abbreviations, I like to keep stuff compact when it's just for demonstration purposes. :D
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
eclectic-tech
Rainmeter Sage
Posts: 5406
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA

Re: [FEATURE] BevelType Color

Post by eclectic-tech »

The delay in adjusting the bevel background size based on Shape can be removed by a 'brute force' double [!Update] in the scroll bang. Not elegant, but it eliminates the delay in redrawing the shapes to the new dimensions.

Your shape was based on variables that were not changing when the font size was changed, so I added actual bevel line shapes and modified the background to use the string meter width and height.

I added a LeftMouseUpAction to the shape meter to switch the shape bevel; simulates changing between Bevel=1 and Bevel=2 in the [Rainmeter] section when using skin backgrounds.

DefaultUpdateDivider=1 allows the skin to update based on changes to skin variables. Setting it to -1 requires the author to add more actions to update skin sections when variables change values.

Code: Select all

[Variables]
SC1=0,0,0
SC2=32,32,32
STC1=224,224,224
STC2=32,32,32
SCA=128
STW=2
FSZ=16
Padding=10
Step=1

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

; Uncomment this and comment [Background] or comment this and uncomment [Background] to see the update differences between using a Bevel or a Shape skin outline

; BackgroundMode=2
; SolidColor=#SC1#,#SCA#
; SolidColor2=#SC2#,#SCA#
; GradientAngle=270
; BevelType=1
; BevelColor=#STC1#,#SCA#
; BevelColor2=#STC2#,#SCA#

; Set this to -1 to see the instant effect, set this to 1 to see the subsequent update effect

DefaultUpdateDivider=1

---Meters---

[Background]
Meter=Shape

Shape=Rectangle (#STW#/2),(#STW#/2),([SomeMeter:W]+#STW#),([SomeMeter:H]+#STW#) | Fill LinearGradient BackgroundGradient | StrokeWidth #STW# | Stroke Color 0,0,0,0
BackgroundGradient=90 | #SC1#,#SCA# ; 0.0 | #SC2#,#SCA# ; 1.0

Shape2=Path ULCorner | StrokeWidth #STW# | Stroke Color #STC1#,#SCA#
ULCorner=(#STW#/2),([SomeMeter:H]+#STW#) | LineTo (#STW#/2),(#STW#/2) | LineTo [SomeMeter:W],(#STW#/2)

Shape3=Path LRCorner | StrokeWidth #STW# | Stroke Color #STC2#,#SCA#
LRCorner=([SomeMeter:W]+#STW#),(#STW#/2) | LineTo ([SomeMeter:W]+#STW#),([SomeMeter:H]+#STW#) | LineTo (#STW#/2),([SomeMeter:H]+#STW#)

DynamicVariables=1
LeftMouseUpAction=[!WriteKeyValue Variables STC1 #STC2#][!WriteKeyValue Variables STC2 #STC1#][!Refresh]

[SomeMeter]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
FontSize=#FSZ#
AntiAlias=1
Padding=#Padding#,#Padding#,#Padding#,#Padding#
X=0
Y=0
Text="Something"
MouseScrollUpAction=[!SetVariable FSZ (Clamp(#FSZ#+#Step#,7,200))][!Update][!Update]
MouseScrollDownAction=[!SetVariable FSZ (Clamp(#FSZ#-#Step#,7,200))][!Update][!Update]
DynamicVariables=1
User avatar
Yincognito
Rainmeter Sage
Posts: 7164
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [FEATURE] BevelType Color

Post by Yincognito »

eclectic-tech wrote: February 17th, 2022, 4:22 pmThe delay in adjusting the bevel background size based on Shape can be removed by a 'brute force' double [!Update] in the scroll bang. Not elegant, but it eliminates the delay in redrawing the shapes to the new dimensions.
Hm, how could I have missed such a method? :oops:
You're right, excellent idea, but I changed it to avoid the unwanted [!Update] (maybe updating everything is not desirable in the context of other potential measures and such in a real life scenario), and now that you said it I understood what needs to be done, basically some updating in reverse order, coupled with some redraws and hiding / showing the background, see below (the hide / show is for the background to be set properly even on scaling to smaller). Not a fan of unnecessary !WriteKeyValue or !Refresh bangs, so adjusted that to happen during the same loading session too.
eclectic-tech wrote: February 17th, 2022, 4:22 pmYour shape was based on variables that were not changing when the font size was changed, so I added actual bevel line shapes and modified the background to use the string meter width and height.
Actually, that was intentional: what I wanted was a beveled background that could adapt without having to know the size of the elements in the skin, in other words strictly on the - dynamic - current config dimensions built-in variables. I had one method of doing that, but its logic was somewhat not that straightforward as this one turned out to be.
eclectic-tech wrote: February 17th, 2022, 4:22 pmI added a LeftMouseUpAction to the shape meter to switch the shape bevel; simulates changing between Bevel=1 and Bevel=2 in the [Rainmeter] section when using skin backgrounds.
Yep, good addition - didn't bother much with replicating everything done in my actual skins (like diagonal bevel color separation, for example) to this sample skin. Of course, it's you I have to thank for the bevel path idea a while ago as well, I didn't forget that. ;-)
eclectic-tech wrote: February 17th, 2022, 4:22 pmDefaultUpdateDivider=1 allows the skin to update based on changes to skin variables. Setting it to -1 requires the author to add more actions to update skin sections when variables change values.
Yes, but I still prefer skins to be as light as possible on the CPU, even with a Ryzen in my hands, LOL - that will never change. I also happen to prefer updating stuff "on demand" for almost anything bar animations, so both these things suit one another. Even if I wasn't, the method should be capable to work even when using a negative skin update rate.

After your excellent idea and the above modifications, it is more or less:

Code: Select all

[Variables]
SC1=0,0,0
SC2=32,32,32
STC1=224,224,224
STC2=32,32,32
SCA=128
STA=255
STW=2
FSZ=16
Padding=#STW#
Step=1

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

; Uncomment this and comment [Background] or comment this and uncomment [Background] to see the update differences between using a Bevel or a Shape skin outline - SOLVED

; BackgroundMode=2
; SolidColor=#SC1#,#SCA#
; SolidColor2=#SC2#,#SCA#
; GradientAngle=270
; BevelType=1
; BevelColor=#STC#,#SCA#
; BevelColor2=#STC#,#SCA#

; Set this to -1 to see the instant effect, set this to 1 to see the subsequent update effect - SOLVED

DefaultUpdateDivider=-1

---Meters---

[Background]
Meter=Shape
Shape=Rectangle (#STW#/2),(#STW#/2),(#CURRENTCONFIGWIDTH#-#STW#),(#CURRENTCONFIGHEIGHT#-#STW#) | Fill LinearGradient BackgroundGradient | StrokeWidth 0 | Stroke Color #STC#,#SCA#
Shape2=Path ULCorner | StrokeWidth #STW# | Stroke Color #STC1#,#STA#
ULCorner=(#STW#/2),(#CURRENTCONFIGHEIGHT#) | LineTo (#STW#/2),(#STW#/2) | LineTo (#CURRENTCONFIGWIDTH#),(#STW#/2)
Shape3=Path BRCorner | StrokeWidth #STW# | Stroke Color #STC2#,#STA#
BRCorner=(#CURRENTCONFIGWIDTH#-#STW#/2),(0) | LineTo (#CURRENTCONFIGWIDTH#-#STW#/2),(#CURRENTCONFIGHEIGHT#-#STW#/2) | LineTo (0),(#CURRENTCONFIGHEIGHT#-#STW#/2)
BackgroundGradient=90 | #SC1#,#SCA# ; 0.0 | #SC2#,#SCA# ; 1.0
LeftMouseUpAction=[!SetVariable STC1 #STC2#][!SetVariable STC2 #STC1#][!UpdateMeter Background][!Redraw]
DynamicVariables=1

[SomeMeter]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
FontSize=#FSZ#
AntiAlias=1
Padding=#Padding#,#Padding#,#Padding#,#Padding#
X=5
Y=5
Text="Something"
MouseScrollUpAction=[!SetVariable FSZ (Clamp(#FSZ#+#Step#,7,200))][!UpdateMeter SomeMeter][!HideMeter Background][!Redraw][!UpdateMeter Background][!ShowMeter Background][!Redraw]
MouseScrollDownAction=[!SetVariable FSZ (Clamp(#FSZ#-#Step#,7,200))][!UpdateMeter SomeMeter][!HideMeter Background][!Redraw][!UpdateMeter Background][!ShowMeter Background][!Redraw]
DynamicVariables=1
Thank you so much for pointing me in the right direction - you seem to always manage that somehow. :thumbup: :rosegift:
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
eclectic-tech
Rainmeter Sage
Posts: 5406
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA

Re: [FEATURE] BevelType Color

Post by eclectic-tech »

As always, you optimized the skin ;-)

Yes, the main issue is having the meters respond to variable changes without the resizing being noticeable (delayed by one update action).

The use of double updates, whether using !Update, or !UpdateMeter and !Redraw of the affected meter(s), is personal preference, but your method does optimize and focus the actions. :thumbup:

Always happy to kick around ideas :great:
User avatar
Yincognito
Rainmeter Sage
Posts: 7164
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [FEATURE] BevelType Color

Post by Yincognito »

eclectic-tech wrote: February 17th, 2022, 7:38 pmThe use of double updates, whether using !Update, or !UpdateMeter and !Redraw of the affected meter(s), is personal preference...
Don't forget hiding and showing the background - that is absolutely critical for the background (beveled or not) to adapt to a smaller skin size. Thanks to your input I realized why that wasn't happening before: the bigger background prevented the current config dimensions from getting smaller according to the skin's content, so temporarily setting the background dimensions to 0 (by hiding it) allowed proper skin redimensioning to smaller values, before showing the (this time updated) background again. There is some very light flickering once in a while if you look closely, but since there isn't a better method using Shape and the Bevel one is not adjustable... :confused:
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Active Colors
Moderator
Posts: 1254
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany

Re: [FEATURE] BevelType Color

Post by Active Colors »

Thanks eclectic-tech for kicking in and great that Yincognito managed to move further :thumbup:

Yincognito's case reminded me of a similar case I had before https://forum.rainmeter.net/viewtopic.php?t=35740&start=10#p180485.
Based on that, my initial idea was similar to the workaround that eclectic-tech provided. But same as Yincognito I don't like using !Update to update and redraw everything. I would simply add an extra pair of [!UpdateMeter *][!Redraw] at the end of each bang and it would make it work as intended (in the similar manner described in my post from that thread above).

MouseScrollUpAction=[!SetVariable FSZ (Clamp(#FSZ#+#Step#,7,200))][!UpdateMeter *][!Redraw][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetVariable FSZ (Clamp(#FSZ#-#Step#,7,200))][!UpdateMeter *][!Redraw][!UpdateMeter *][!UpdateMeter *]

If you don't like seeing that in front of your eyes you can substitute that with a variable :D
TwinPeaks=[!UpdateMeter *][!Redraw][!UpdateMeter *][!Redraw]
change to !UpdateMeterGroup or #CURRENTSECTION# if needed.

The following answer could also possibly bring some more light about the situation: https://forum.rainmeter.net/viewtopic.php?t=35740&start=10#p180489

P.s. Don't forget that [!UpdateMeter] does not redraw the meter(s). If you have multiple "groups of bangs" in one action sometimes you would need to put [!Redraw] after each "group of bangs" instead of simply having one [!Redraw] as the final bang in the whole action.