It is currently September 21st, 2021, 5:32 pm

Moving the progress bar of a player with a mouse

Help with creating, editing & fixing problems with skins
User avatar
David8192
Posts: 30
Joined: July 8th, 2021, 11:30 pm

Moving the progress bar of a player with a mouse

Post by David8192 »

My Neon suite works fine. I just need to fine tune the progress bar on the music player. I tried both $MouseX$ and $Mouse:%X$ to get the position of the mouse but it is way off. How can I get a precise position for the mouse click. The meters for the player are in the bar.ini file.
You do not have the required permissions to view the files attached to this post.
Golden at Heart
 
Normal is weird
.  
User avatar
death.crafter
Posts: 937
Joined: April 24th, 2021, 8:13 pm

Re: Moving the progress bar of a player with a mouse

Post by death.crafter »

David8192 wrote: July 29th, 2021, 1:25 am My Neon suite works fine. I just need to fine tune the progress bar on the music player. I tried both $MouseX$ and $Mouse:%X$ to get the position of the mouse but it is way off. How can I get a precise position for the mouse click. The meters for the player are in the bar.ini file.
It is either ($MouseX$/TotalLength)*100 or $MouseX:%$(not $Mouse:%X$)
from the Realm of Death
My Current Desktop
User avatar
Yincognito
Rainmeter Sage
Posts: 4052
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Moving the progress bar of a player with a mouse

Post by Yincognito »

Your original meter:

Code: Select all

[ProgressBar]
Meter=Shape
Shape=Rectangle 70,15,300,20,10 | FillColor 0,0,0,0 | Stroke Lineargradient Grad2
Shape2=Rectangle 70,15,([Progress]*3),20,10 | Extend MyG
MyG=Stroke Lineargradient Grad | Fill Lineargradient Grad2| StrokeWidth 2 
Grad=GradientColor | 270 | [DesktopFG1] ; 0.0 | [DesktopFG2] ; 0.5 | [DesktopBG2] ; 1.0
Grad2=GradientColor | 270 | [DesktopBG1] ; 0.0 | [DesktopBG2] ; 0.5 | [DesktopBG2] ; 1.0
DynamicVariables=1
LeftMouseUpAction=[!CommandMeasure "Player" "SetPosition $MouseX:%$"]
The much easier to work with (and pointing out correctly on mouse click) one:

Code: Select all

[ProgressBar]
Meter=Shape
X=70
Y=15
Shape=Rectangle 0,0,300,20,10 | FillColor 0,0,0,0 | Stroke Lineargradient Grad2
Shape2=Rectangle 0,0,([Progress]*3),20,10 | Extend MyG
MyG=Stroke Lineargradient Grad | Fill Lineargradient Grad2| StrokeWidth 2 
Grad=GradientColor | 270 | [DesktopFG1] ; 0.0 | [DesktopFG2] ; 0.5 | [DesktopBG2] ; 1.0
Grad2=GradientColor | 270 | [DesktopBG1] ; 0.0 | [DesktopBG2] ; 0.5 | [DesktopBG2] ; 1.0
DynamicVariables=1
LeftMouseUpAction=[!CommandMeasure "Player" "SetPosition $MouseX:%$"]
I will never understand why on earth do people choose to start their Shape meter rectangles from another position than 0,0 since that leads to a lot of side effects (this was one of them). Sure, there may be times when the first two parameters of a Shape meter rectangle would have to be different than 0,0 but this is certainly not the case, because then you'd have to subtract 70 (i.e. the horizontal point where your rectangle starts in the meter) from the meter's width, use pixel $MouseX$ coordinates instead of $MouseX:%$ percentage ones, and do the conversion back to a percentage manually yourself. All in all, it would require a formula longer than desired, and most likely not directly applicable in the !CommandMeasure bang since the parameters are plain strings (so, it would also require a suited Calc measure to get the result and use it here).

Bottom line, additional effort and code just because you didn't set the (70,15) position through the meter's X and Y and instead started the rectangles from 70,15. Really inefficient, if you ask me, because, if the above wasn't enough, setting position from the Shape parameters instead of the meter parameters artificially increases the size of the meter with "empty space" as well, having an impact on the skin's CPU usage as well, for more complex and larger skins.
User avatar
David8192
Posts: 30
Joined: July 8th, 2021, 11:30 pm

Re: Moving the progress bar of a player with a mouse

Post by David8192 »

:jawdrop
by Yincognito » Today, 4:03 pm
Your original meter:

Code: Select all

[ProgressBar]
Meter=Shape
Shape=Rectangle 70,15,300,20,10 | FillColor 0,0,0,0 | Stroke Lineargradient Grad2
Shape2=Rectangle 70,15,([Progress]*3),20,10 | Extend MyG
MyG=Stroke Lineargradient Grad | Fill Lineargradient Grad2| StrokeWidth 2
Grad=GradientColor | 270 | [DesktopFG1] ; 0.0 | [DesktopFG2] ; 0.5 | [DesktopBG2] ; 1.0
Grad2=GradientColor | 270 | [DesktopBG1] ; 0.0 | [DesktopBG2] ; 0.5 | [DesktopBG2] ; 1.0
DynamicVariables=1
LeftMouseUpAction=[!CommandMeasure "Player" "SetPosition $MouseX:%$"]

The much easier to work with (and pointing out correctly on mouse click) one:

Code: Select all

[ProgressBar]
Meter=Shape
X=70
Y=15
Shape=Rectangle 0,0,300,20,10 | FillColor 0,0,0,0 | Stroke Lineargradient Grad2
Shape2=Rectangle 0,0,([Progress]*3),20,10 | Extend MyG
MyG=Stroke Lineargradient Grad | Fill Lineargradient Grad2| StrokeWidth 2
Grad=GradientColor | 270 | [DesktopFG1] ; 0.0 | [DesktopFG2] ; 0.5 | [DesktopBG2] ; 1.0
Grad2=GradientColor | 270 | [DesktopBG1] ; 0.0 | [DesktopBG2] ; 0.5 | [DesktopBG2] ; 1.0
DynamicVariables=1
LeftMouseUpAction=[!CommandMeasure "Player" "SetPosition $MouseX:%$"]

I will never understand why on earth do people choose to start their Shape meter rectangles from another position than 0,0 since that leads to a lot of side effects (this was one of them). Sure, there may be times when the first two parameters of a Shape meter rectangle would have to be different than 0,0 but this is certainly not the case, because then you'd have to subtract 70 (i.e. the horizontal point where your rectangle starts in the meter) from the meter's width, use pixel $MouseX$ coordinates instead of $MouseX:%$ percentage ones, and do the conversion back to a percentage manually yourself. All in all, it would require a formula longer than desired, and most likely not directly applicable in the !CommandMeasure bang since the parameters are plain strings (so, it would also require a suited Calc measure to get the result and use it here).

Bottom line, additional effort and code just because you didn't set the (70,15) position through the meter's X and Y and instead started the rectangles from 70,15. Really inefficient, if you ask me, because, if the above wasn't enough, setting position from the Shape parameters instead of the meter parameters artificially increases the size of the meter with "empty space" as well, having an impact on the skin's CPU usage as well, for more complex and larger skins.
Thank you sooo... much! It works! I will remember this input because I have some more ideas to smash shapes and mouse detection together. Thanks again, Yincognito.
Golden at Heart
 
Normal is weird
.  
User avatar
Yincognito
Rainmeter Sage
Posts: 4052
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Moving the progress bar of a player with a mouse

Post by Yincognito »

David8192 wrote: July 29th, 2021, 3:31 pm :jawdrop
Thank you sooo... much! It works! I will remember this input because I have some more ideas to smash shapes and mouse detection together. Thanks again, Yincognito.
No problem - glad to help. Just make sure you take into consideration such factors when designing shapes. Most of the times it works better this way, but there are times when your original way is more suited (when rotating a rectangle, just an example). ;-)
User avatar
David8192
Posts: 30
Joined: July 8th, 2021, 11:30 pm

Re: Moving the progress bar of a player with a mouse

Post by David8192 »

Yincognito wrote: July 29th, 2021, 5:09 pm No problem - glad to help. Just make sure you take into consideration such factors when designing shapes. Most of the times it works better this way, but there are times when your original way is more suited (when rotating a rectangle, just an example). ;-)
Got it. :bow: I will keep that in mind as well.
Golden at Heart
 
Normal is weird
.