Yincognito wrote: ↑February 19th, 2019, 4:37 pm
Not me. What is important for me in this case is that all the TransformationMatrix limitations can be nullified using workarounds. Sure, a workaround is never the best solution, and these particular workaround might involve more complex math, but the bottom line is, the limitations can be nullified.
That's as close to a perfect explanation of why it is terrible that I can think of. I rest my case...
jsmorley wrote: ↑February 19th, 2019, 3:24 pm
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, as well as relative positioning of subsequent meters.
Agree.
jsmorley wrote: ↑February 19th, 2019, 3:24 pm
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. One could argue that this is a limitation of those meter types as much as it is of TransformationMatrix, but tomato, tomato.
Disagree. It can be used on both, Button and Bitmap meters, even if the help of both type of meters says it can't be.
To demonstrate this, see the attached skin. It is a rotating globe, which is created as a Bitmap meter. If you left click the globe it is inclined with 23 degree (you can modify the angle into the [Variables] section) and if you right click it is enlarged (at next left or right click the inclination and enlarge is restored). Both are done with TransformationMatrix.
jsmorley wrote: ↑February 19th, 2019, 3:24 pm
3) Today at least, it can't be effectively used with the new Container option.
I didn't test it with the Container option, but yes, probably this is true as well.
TransformationMatrix is not a such hard thing as it seems at a first look. It has a math involved, but it's working. Its greatest disadvantage is what you've said at point 1). The Transformation Matrix Guide is a very well written and very useful document when working with this option.
I love this powerful option.
You do not have the required permissions to view the files attached to this post.
In my view, all you should need for scaling is an amount in X an amount in Y and an anchor point. For rotation, all you should need is a positive or negative amount, and an anchor point. There is no excuse for this being so complicated.
balala wrote: ↑February 19th, 2019, 4:47 pmDisagree. It can be used on both, Button and Bitmap meters, even if the help of both type of meters says it can't be.
To demonstrate this, see the attached skin. It is a rotating globe, which is created as a Bitmap meter. If you left click the globe it is inclined with 23 degree (you can modify the angle into the [Variables] section) and if you right click it is enlarged (at next left or right click the inclination and enlarge is restored). Both are done with TransformationMatrix.
Well, it seems you are right. Just tested your transformation matrix coordinates for the button meter, and it worked as well. It doesn't have clickable issues either, the clicks work only on the resized button, not on the un-resized one, so it's all good. The OP can just put your TransformationMatrix=0.5;0;0;0.5;9;27 option in the [MT_Launcher_Button] section and it will work without photoshoping things all over again. Yay!
By the way, great globe you have there! If the animations in general would use less CPU, I would keep it as my actual wallpaper (which is also a globe, but static .jpg). As the OP use to say, you just won my heart, balala!
Yincognito wrote: ↑February 19th, 2019, 5:03 pm
By the way, great globe you have there! If the animations in general would use less CPU, I would keep it as my actual wallpaper (which is also a globe, but static .jpg).
I didn't check how this skin affects the CPU usage it can increase and my goal was not this, but only to demonstrate how the TransformationMatrix can be applied on both types of meters, Button and Bitmap.
Yincognito wrote: ↑February 19th, 2019, 5:03 pm
As the OP use to say, you just won my heart, balala!
I'm glad.
Generally speaking, I think most users are afraid to work with TransformationMatrix, because most of them think it is too complicated. But it's not, I still say it's not. But yes, it also took me a lot of time until I got used to use it, but now I simply just love it (as I said before).
jsmorley wrote: ↑February 19th, 2019, 5:00 pm
I still rest my case...
Yes, this can look terrifying, but it's not. I wrote it using the mentioned Transformation Matrix Guide.
The first four elements of this option is basically the trigonometric functions of the inclination angle. I had to multiply the #Angle# with #Rotation# and the trigonometrical function with (#Grow#+1), to can control how the TransformationMatrix affects the meter when you left- or right-click it.
The last two parameters are the tx and ty parameters, as described in the Transformation Matrix Guide, to keep the "transformed" meter unmoved from its initial position. I didn't add concrete values for the parameters, instead I used the position and the size of the current meter, to have the meter inclined around its own center when you left click it. For example ([#CURRENTSECTION#:X]+[#CURRENTSECTION#:W]/2) and ([#CURRENTSECTION#:Y]+[#CURRENTSECTION#:H]/2) are the coordinates of the center of meter, around which I wanted to rotate the globe.
The option could be written much more simpler, but in this case it would be static. With the written TransformationMatrix if you enlarge the 1.png image using Photoshop or any image manipulation software, getting it a different size (larger or smaller), the inclination and enlargement still will properly work. That's why it became so frighteningly complicated.
balala wrote: ↑February 19th, 2019, 5:12 pmBut it's not, I still say it's not. But yes, it also took me a lot of time until I got used to use it, but now I simply just love it (as I said before).
Exactly my case. You do have to be able to do some math for that though. For me and you it won't be such a big problem, but for others it might very well be - like jsmorley already said.
..............................
Coming back to the subject of this topic, here it's the updated code for the launcher skin - just replace the previous one in Launcher2.ini and you're good to go:
Thing is, because of the way TransformationMatrix works, the launcher items must be positioned outside the original coordinates of the launcher button, since if you don't, the launcher item meters will trigger the launcher button reaction (e.g. visual and sound changes) when you hover or click on them. This is easily seen by uncommenting the ;Y=([MT_Launcher_Button:Y]+[MT_Launcher_Button:H]*#ResizeFactor#+5) line and commenting the following one in the [MT_LauncherItem1] section. Any ideas on how to workaround that, balala - other than moving the launcher item meters outside the original launcher meter coordinates?
EDIT: I managed to partially workaround the above issue, by moving the action bangs to [MT_Launcher_Text] instead of [MT_Launcher_Button], but, of course, the button itself still changes visually when hovered on the items, since this isn't controlled by action bangs that you can move.
EDIT 2: Realizing that the launcher button reacted like the above only when the mouse was over non-transparent pixels of other meters (like the launcher item meters ones), I tried to put [MT_Launcher_Button] into a Container meter (to make things outside the button "invisible for the button itself", if it makes any sense, LOL), and while this kind of "worked", it also made the entire button transparent, for some reason - not just the button part that is outside the container...
