It is currently March 28th, 2024, 4:08 pm

TransformationMatrix with MouseOverAction

Report bugs with the Rainmeter application and suggest features.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: TransformationMatrix with MouseOverAction

Post by jsmorley »

Is the pixel my mouse is on solid, and I don't care what made it solid, and is it within the boundaries defined by the meter this mouse action is on?
I think this skin demonstrates a lot of what I'm talking about.

Code: Select all

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

[Variables]

[MeterOne]
Meter=Image
W=200
H=200
SolidColor=255,0,0,110
MouseOverAction=[!SetOption MeterOne SolidColor "255,0,0,255"][!UpdateMeter MeterOne][!Redraw]
MouseLeaveAction=[!SetOption MeterOne SolidColor "255,0,0,110"][!UpdateMeter MeterOne][!Redraw]
LeftMouseUpAction=[!Log "Meter One"]

[MeterTwo]
Meter=Image
X=100
Y=100
W=200
H=200
SolidColor=0,255,0,255
MouseOverAction=[!SetOption MeterTwo SolidColor "0,255,0,255"][!UpdateMeter MeterTwo][!Redraw]
MouseLeaveAction=[!SetOption MeterTwo SolidColor "0,255,0,110"][!UpdateMeter MeterTwo][!Redraw]
MouseActionCursor=0
;LeftMouseUpAction=[!Log "Meter Two"]
If you run this and move your mouse over it, you will see that any time the mouse is over the red square, even if it is "behind" the green square, that MouseOverAction is seen. If the mouse is over the part of the green square that doesn't overlap the red square, only that MouseOverAction is seen. If the mouse is over both, where they overlap, both MouseOverAction's are seen.

The MouseActionCursor=0 on [MeterTwo] helps to see what is going on. See that it changes to the "hand", when over the red square, even when on the part behind the green square.

As far as LeftMouseUpAction is concerned, it's similar, but with one big difference. As long as only [MeterOne] has a LeftMouseUpAction, that is fired when the mouse is over that square, even the part behind the green square. However, if BOTH meters have a LeftMouseUpAction, (uncomment that one on [MeterTwo] to see) Then the one in front (later in the skin .ini file) is fired when the mouse is in a position where the squares overlap. It will never fire both.

So to "protect" a meter from having a LeftMouseUpAction (or any click action) fired when you are over it, and there is a meter (or the skin background) behind it that has a LeftMouseUpAction, you can add:

LeftMouseUpAction=[]

To the meter, and it will ignore clicks that are on any part of it, even if something behind it has a mouse action.

In keeping with another discussion, note that this is LeftMouseUpAction=[], NOT LeftMouseUpAction="" or LeftMouseUpAction=. We don't want NO bang, we want a valid bang that just doesn't do anything.

Just be aware that there is no such "protection" for MouseOverAction. Any and all MouseOverAction's when the cursor is on a solid pixel that is within the boundaries of any meter with the MouseOverAction will be fired.
F!.OW
Posts: 22
Joined: April 1st, 2018, 12:42 pm

Re: TransformationMatrix with MouseOverAction

Post by F!.OW »

jsmorley wrote:It is the nature of how it works. TransformationMatrix does not alter the size and shape of the meter, and mouse actions are based on the meter.

https://docs.rainmeter.net/manual/meters/general-options/#TransformationMatrix

It's one of the reasons that I don't personally think TransformationMatrix is the best route for a hover effect like this. I would just make the FontSize larger, and let the meter grow to accommodate it.

A lot of folks really like TransformationMatrix. I personal find the fact that is makes mouse actions and relative positioning problematic to be pretty much a show-stopper. I think it has its uses, but they are not as general as it might seem at first glance.
Thanks for the explanation. I've been over the manual many times and sometimes you just miss parts because they didn't apply at the time.

In any case, I had no intention of using TransformationMatrix in my example above. I used it merely for illustrative purposes, to get me problem across. So often I see people asking for help and they're just so vague with what's happening. I'd be applying this more to working with Shapes.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: TransformationMatrix with MouseOverAction

Post by jsmorley »

Shape meters have an entirely different approach to mouse detection.

https://docs.rainmeter.net/manual/meters/shape/#MouseDetection
F!.OW
Posts: 22
Joined: April 1st, 2018, 12:42 pm

Re: TransformationMatrix with MouseOverAction

Post by F!.OW »

jsmorley wrote:Shape meters have an entirely different approach to mouse detection.

https://docs.rainmeter.net/manual/meters/shape/#MouseDetection
I understand, thanks.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: TransformationMatrix with MouseOverAction

Post by jsmorley »

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
SkinWidth=310
SkinHeight=240
AccurateText=1

[MeterShape]
Meter=Shape
Shape=Rectangle 2,2,100,75
TransformationMatrix=3.00;0;0;3.00;0;0
LeftMouseUpAction=[]
As you will see, the entire "transformed" shape sees the mouse, unlike with other meters. That is because mouse detection on Shape meters is on the "shape" and not the "meter".

SolidColor is also a bit different on Shape using TransformationMatrix, as the SolidColor will be applied to the entire transformed background of the "shape" instead of the "meter". Don't be fooled though, the meter itself, for purposes of relative positioning and getting the size with things like [MeterName:W] will still be the original untransformed size.

Be careful in addition, that DynamicWindowSize=1 WON'T see the expanded shape, as that is dependent on the size based on meters. In that case, you want to be sure you size the overall skin window large enough.


This is a case where I think TransformationMatrix is a poor choice indeed. I'd be tempted to use "Scale" on the Shape meter, which will cause the actual meter to become the scaled size, and relative positioning and such will be more logical. In addition, DynamicWindowSize will then work...

Code: Select all

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

[MeterShape]
Meter=Shape
Shape=Rectangle 2,2,100,75 | Scale 3.0, 3.0, 0, 0
;TransformationMatrix=3.00;0;0;3.00;0;0
LeftMouseUpAction=[]

[MeterString]
Meter=String
Y=10R
FontSize=11
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text=Hello World
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: TransformationMatrix with MouseOverAction

Post by jsmorley »

And using that to solve our TransformationMatrix >> MouseOverAction / Relative position issues on the String meter:

Code: Select all

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

[Variables]
ScaleFactor=1.0

[MeterString]
Meter=String
FontSize=15
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=10,10,10,10
AntiAlias=1
Text=Mouse Off
TransformationMatrix=#ScaleFactor#;0;0;#ScaleFactor#;0;0
DynamicVariables=1

[MeterShape]
Meter=Shape
Shape=Rectangle [MeterString:X],[MeterString:Y],[MeterString:W],[MeterString:H] | Scale #ScaleFactor#, #ScaleFactor#, 0, 0 | StrokeWidth 0 | Fill Color 0,0,0,1
DynamicVariables=1
MouseOverAction=[!SetOption MeterString Text "Mouse Over"][!SetVariable ScaleFactor "1.5"][!SetOption MeterString SolidColor "90,90,90,255"][!UpdateMeter *][!Redraw]
MouseLeaveAction=[!SetOption MeterString Text "Mouse Off"][!SetVariable ScaleFactor "1.0"][!SetOption MeterString SolidColor "47,47,47,255"][!UpdateMeter *][!Redraw]
LeftMouseUpAction=[]

[MeterRelative]
Meter=String
Y=10R
FontSize=15
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text=Relative!
GIF.gif
Just have the Shape meter match the position and size of the "untransformed" String meter, then "scale" it the same amount you "transformed" the String meter. In this case by a factor of 1.5, using the top left as the anchor.

Meters that are then relative to the Shape meter will be positioned correctly, as unlike TransformationMatrix, using Scale on a Shape meter actually changes the size of the meter itself.

I think that using a "scaled" Shape meter for this, rather than a "sized" Image meter with calculated X/Y/W/H is more precise and appeals to me, as X/Y/W/H on meters cannot be fractional. Not sure there would be any appreciable difference really, but it just feels more "correct" to me.
F!.OW
Posts: 22
Joined: April 1st, 2018, 12:42 pm

Re: TransformationMatrix with MouseOverAction

Post by F!.OW »

jsmorley wrote:And using that to solve our TransformationMatrix >> MouseOverAction / Relative position issues on the String meter: ...

I think that using a "scaled" Shape meter for this, rather than a "sized" Image meter with calculated X/Y/W/H is more precise and appeals to me, as X/Y/W/H on meters cannot be fractional. Not sure there would be any appreciable difference really, but it just feels more "correct" to me.

This is awesome
, thanks jsmorley! Much appreciated.

I agree, using Shape over Image makes more sense.
Post Reply