Meter following the mouse

[Maurdekye]

I tried making a circle that follows your mouse;

[MouseMeter]
Meter=Roundline
AntiAlias=1
Solid=1
LineColor=200,20,20
StartAngle=0
RotationAngle=6.28
LineStart=0
LineLength=10
DynamicVariables=1
W=20
H=20
X=0
Y=0
OnUpdateActon=[!SetOption MouseMeter X $MouseX$][!SetOption MouseMeter Y $MouseY$][!Redraw]

But it just stays in the corner.

[jsmorley]

The $Mouse$ variables are only populated on a mouse click action. So when you use OnUpdateAction, and are looking to retrieve and use the current mouse position, it won't work.

Usage

The variables are only created and used in the context of a mouse click or scroll action. Primarily, they will be used as a parameter to a Bang. For instance:

LeftMouseUpAction=[!SetOption SomeMeter X $MouseX$][!UpdateMeter *][!Redraw]
LeftMouseUpAction=!CommandMeasure ScriptMeasure GetRGB($MouseX$,$MouseY$)

Before you go to the trouble to test with MouseOverAction / MouseLeaveAction, that won't work. The $Mouse$ macro is only fired on a mouse click or scroll wheel action.

There is no way in Rainmeter to do what you are trying to do. You can't have a skin "follow" the mouse on the screen.

Understand that this is due to a conscious decision not to try to have Rainmeter keeping track of the mouse position at all times, to enable returning the position anytime the $Mouse$ variables are used. To do this without the "known" position being hopelessly behind the actual position of the mouse on the screen would require polling for the mouse position pretty much every millisecond. This would be terrible for Rainmeter's use of resources, and in any case would still always be hideously behind in an environment that is based on the skin update rate. Instead, getting the position is "event based", and it returns the position of the mouse when a button is clicked or the wheel is scrolled.

[Maurdekye]

Huh. Well, there must be a way in lua. I'll look into that.

[jsmorley]

Huh. Well, there must be a way in lua. I'll look into that.

You will find there is not...

Aside from the fact that Lua is OS agnostic, and the standard libraries don't support dealing with the mouse, it still remains true that any process you use to track the current position of the mouse at all times will be hopelessly, hideously behind when you react to it in a skin that is updating once a second. Even if you set the Update rate of the skin to 10 or 15, the lowest possible value in Rainmeter, the mouse can have moved hundreds of pixels long before the skin has any hope of setting the position of some meter.

So even if I wrote an AutoIt executable that I have running in the background at all times, just constantly firing bangs to Rainmeter to update some variable with the position, I would still just have something that both causes Rainmeter to use a ton of CPU and in any practical sense just wouldn't work anyway. If I wrote it to send a !SetOption for a meter, followed by an !UpdateMeter and !Redraw, to get around the skin update rate, doing that every millisecond would just bring Rainmeter, and perhaps your entire computer, to its knees.

[Maurdekye]

That kind of sucks.

[rm_lion]

would just bring Rainmeter, and perhaps your entire computer, to its knees.

LOL!
That reminds me of the Time when I was working for a big Swiss Insurance. I was programming in COBOL and I made a Loop in my Program that did even bring the OS/390 IBM Host to it's knees!

[jsmorley]

That kind of sucks.

It helps to understand that Rainmeter isn't like most other Windows "applications" that basically draw some user interface, then just put themselves in a very tight "loop" that basically does nothing at all but wait for mouse or keyboard events in Windows. That loop just runs as fast as your computer hardware will allow. Measured in sub-millisecond speeds.

Rainmeter on the other hand has skins in a loop based on the update rate of the skin, and inside the loop it is firing measures, updating meters, and redrawing the screen. That is why for all practical purposes, the lowest Update value you can set in Rainmeter is around 10 milliseconds. Less than that and there just isn't time to do the work a skin requires, even a simple one. While Rainmeter won't complain or fail if you set Update=1, for all practical purposes that is still around Update=10, it can only do things as fast as it can do things. The minimum update value that will "work" in a skin is somewhat dependent on how much the skin is doing. Might be 10, might be 20... That is why you never base a clock in Rainmeter on the update rate, and why we will never have clocks that measure in milliseconds.

While Rainmeter does watch and react to mouse click and scroll wheel events from Windows, it is not the kind of purely "event driven" environment that say Calculator or Notepad is. While I don't doubt that we could add a MouseMoveAction to Rainmeter, in our environment it just wouldn't do any good. The skins could just never, ever keep up in any realist way.

[killall-q]

When I made T-Minus I originally set it to 100 FPS (10 ms update). I set up a simple counter output to log and found that it couldn't maintain a framerate even close to that. I settled on 40 FPS as a barely maintainable FPS (it still dips to 38-39) that is still perceived as smooth by the human eye.