balala wrote: ↑July 10th, 2021, 6:25 pmNo, actually you were not. [...] A such SkinTransformationMatrix option, applied to the [Rainmeter] section is not valid (unless I'm missing something - but to be honest I doubt I do).
balala wrote: ↑July 10th, 2021, 6:46 pmAs I posted in my above reply as well, still not clear what the "skin level TransformationMatrix" does mean. Transformation matrices can be applied
ONLY to meters, but there you can apply as many such transformation matrices as you want, by simply multiplying all of them together.
Yes, you're missing something: transformation matrices can be applied to ANY point in space - there are even 4x4 matrices that are used in 3D software. The mathematical concept doesn't care whether it's a "skin", "meter" or whatever structure Rainmeter works with or whether it's "valid" for that narrow case - it can literally be applied to ANYTHING that is an "object" in space (2D, 3D, etc), assuming, of course, that a corresponding implementation were to be written. That being said, what you're talking about relates to the
current implementation of Rainmeter, in which such an option obviously doesn't exist at the skin level, only at a meter level. That doesn't mean it can't be done at the skin level though, and became "valid" as a result. Nothing in this world is "valid" ...
until it is actually built (and then folks take it for granted, forgetting they rated the thing as "unclear", "impossible" and so on beforehand).
death.crafter wrote: ↑July 10th, 2021, 6:45 pmWell the answer is a big no, but, well, he got it partially working. But since TM doesn't apply to boundaries, it can not be implemented on a skin level, considering containers and such things.
Well, maybe my eyesight is faulty, but I see a big yes, since I posted a fully working result as proof.
You are correct that there are some exceptions (aren't they always?), but then I didn't see so many folks overly concerned over the SAME issues a transformation matrix ALREADY has with
containers,
mouse actions or
input texts even on a meter level. It's not that "it can not be implemented on a skin level", it's just that doing so will produce the same drawbacks as at a meter level.
Also, bear in mind that I didn't necessarily mean that a skin level transformation / scaling should be done using the current TM approach, see
here (similar transformations exist for Shape meters and work much better, by the way - too bad they can't be applied outside shapes). I only took that "skin level TM" under consideration for two reasons: it was available to test it in a simulated environment (even though the option itself doesn't exist) and to answer a question related to whether a skin level transformation would be possible for already transformed meters (which I proved to be possible). The drawbacks or the exceptions you guys mention, well, those are not my responsibility, and they don't make the method / approach
itself less valid or possible. In other words, if TM already had 0 drawbacks and exceptions, my approach would have been flawless - correct me if I'm wrong.
P.S. I don't want to put pressure on the devs or criticize their work, to be perfectly clear - I fully understand the difficulty of programming something and having to take care of a thousand things at the same time. My take was just a simple "proof of concept", if you like.
