jsmorley wrote: ↑February 19th, 2019, 3:24 pm
TransformationMatrix is indeed very powerful, but it has limitations that need to be understood.
1) Using it does not effect the size or orientation of the "meter", and that will have some very problematic impacts on mouse detection on the meter.
2) It can't effectively be used with all meter types, Button being one. Bitmap being another. That is because those are based on the image being "divided" into "frames" and that will use the original size, not the transformed size.
3) Today at least, it can't be effectively used with the new Container option.
I actually don't like TransformationMatrix. In my view the fact that it doesn't alter its parent meter's size or orientation is a show-stopper a lot of the time, and in any case, it is way too complicated to use for my tastes. We are looking at some alternatives for "scaling" and "rotating" that might not be quite as powerful, but simpler to use going forward.
Hopefully, it won't be deprecated though. I avoided it for a long time, being pushed back by its apparent complexity, but once I started working with it, I came to like it a lot and understood how it works. It became clear to me that we can't safely use it for "clickable" elements (due to the limitations you mentioned), but for simple transformations like shrinking and enlarging, the way I've workarounded the unalterable size of the meter was to "retain" the meter's initial coordinates at the start in corresponding variables, and then perform the transformations based on that, instead of getting the (wrong/unupdated) coordinates the classical way (e.g.
[Meter:X-Y-W-H] on each update). Of course, this won't work for more complex transformations like skewing and such, but for simple resizing of non clickable elements, it does its job.
NOTE: If I think about it, since every meter is, after all, a rectangle (irrespective of its visible shape), this workaround might work for skewing as well, if you one "retains" the initial (i.e. first skin update) coordinates, like the meter rectangle's four "corner" coordinates. I don't know how this is done in the Rainmeter's source code, but it could be an (imperfect) solution there as well. Just saying...