Weird MouseOverAction interaction with multiple transparent Image meters

[DimasDSF]

It seems as if MouseOver detection has an issue determining whether or not the pixel under the cursor belongs to the meter that has mouseoveraction and only checks the bounding box.

Setup for replicating:

Code: Select all

[Rainmeter]
Update=500

[MeterDetection]
Meter=Image
X=10R
Y=0
W=10
H=10
SolidColor=255,0,0,255

[MeterTriangle]
Meter=Image
ImageName=Resources/Triangle.png
MouseOverAction=[!SetOption MeterDetection SolidColor 0,255,0,255]
MouseLeaveAction=[!SetOption MeterDetection SolidColor 255,0,0,255]

[MeterButton]
Meter=Image
ImageName=Resources/Button.png

rmskin file:
https://drive.google.com/file/d/12T7ULzqBUSypZbQqt6eujVksH10EiIrE/view?usp=sharing

Expected behavior:
- Top left box only turns green when hovering over the red triangle
- Top left box stays red when hovering over the green box

Current behavior:
- Top left box turns green when hovering over any part of the skin that is inside the red triangles bounding box

[ikarus1969]

That's the normal behavior. Only if you use shapes Mouse-Actions work on the non-transparent pixels of the shape.
So create a triangle as a shape with the same mouse-actions and it will work.

[DimasDSF]

That's the normal behavior. Only if you use shapes Mouse-Actions work on the non-transparent pixels of the shape.
So create a triangle as a shape with the same mouse-actions and it will work.

Uhm... this is a reproduction demo, I don't really want just a triangle, I understand it might be a performance optimization but still it would be nice to be able to enable a more precise behavior for when it matters more than a couple of CPU cycles, for example any time a picture more complex than a couple of triangles is needed

[ikarus1969]

As i said if you want pixel-exact behavior with mouse-actions you would need to compose your picture - no matter how complex or simp,le it is - of one or more shapes.
Normal images always will react only to their bounding-box.

[DimasDSF]

It would be nice to hear from a developer if this is ever going to be considered as a feature or why it is not.

And if it is impossible from a programming standpoint to detect the specific meter the cursor hovers above there should be a notice added to the documentation informing of this behavior.

[ikarus1969]

I agree that it should be noted on the description of the meter or Mouse-Actions too. The best i can find is at https://docs.rainmeter.net/manual/meters/shape/#MouseDetection
But let's see if any of the developers may read this thread.

[Yincognito]

Expected behavior:
- Top left box only turns green when hovering over the red triangle
- Top left box stays red when hovering over the green box

Current behavior:
- Top left box turns green when hovering over any part of the skin that is inside the red triangles bounding box

Well, for me, the top left box turns green when hovering over any of the 3 geometric figures, and it does not turn green when on the transparent pixels in the skin, even if they are "inside the red triangle bounding box". Like ikarus1969 mentioned, it's the standard and expected behavior for images. Depending on how volatile your images are (i.e. if they are not moving, rotating or otherwise changing), you could workaround this by adding 0,0,0,1 colored Shape meters that resemble the images on top of them, and trigger the mouse actions on those Shape meters instead.

P.S. Even if the devs answer this, I doubt the behavior will be changed. After all, this is one of the reasons why Shape meters exist. Even if the behavior could be changed, this would break backward compatibility for a lot of previous skins that might rely on that.

[Brian]

Mouse detection is detected by meter boundaries (except for the Shape meter). This means overlapping meters can trigger mouse actions from other meters since the mouse is technically over the same meter - as long as there is any non-transparent pixel showing from the skin.

The order of mouse actions performed on any pixel depends on the z-order of the meter. When the mouse action is performed, Rainmeter first looks at the topmost meter and executes any mouse actions if needed, then it looks at the next meter layer down and executes those mouse action if needed. And so on. Any mouse action defined in the [Rainmeter] section are performed last.

I believe the Shape meter is the only mouse detection that is different.


If you have overlapping meters, you might be able to re-order them to achieve your desired behavior. In your example, if you place the button before the Triangle and declare some extra mouse actions, you can get different results.

Code: Select all

[Rainmeter]
Update=500

[MeterDetection]
Meter=Image
X=10R
Y=0
W=10
H=10
SolidColor=255,0,0,255

[MeterButton]
Meter=Image
ImageName=Resources/Button.png
MouseOverAction=[!SetOption MeterDetection SolidColor 255,0,0,255]
MouseLeaveAction=[!SetOption MeterDetection SolidColor 255,0,0,255]

[MeterTriangle]
Meter=Image
ImageName=Resources/Triangle.png
MouseOverAction=[!SetOption MeterDetection SolidColor 0,255,0,255]
MouseLeaveAction=[!SetOption MeterDetection SolidColor 255,0,0,255]

This way the Triangle triggers the color change, and the button doesn't (at least visually). I am not sure if that will help you in your "real" skin.

-Brian

[Yincognito]

The funny thing is that I tried what Brian did by reordering meters, but since I didn't add conservative mouse actions on the button, I couldn't replicate the button staying red. Thanks to him, I guess now you have both parts from your expected behavior working.

In the real skin scenario, the only problem that may arise is if you want the button to do "nothing" at all, but even then you can set things "back" to how they were, assuming you know or store those "default" states somewhere. A bit inconvenient, especially if you have lots of such buttons that you expect to preserve the current state of variables or colors in this case, but still quite possible.

EDIT: I wonder if you could fully replicate the desired behavior by using a Container meter based on the same red triangle image... I mean, the container will draw only the opaque pixels in the image anyway, so it might just be a reasonable solution to this, if mouse actions comply with it. Can't test it ATM, but I don't see why it shouldn't work...

EDIT2: Tried it, didn't get the expected result, so it looks that Brian's solution is the way to go, after all.