Building a mini Launcher!!!! My last request.

[Yincognito]

Edit 2 : OMG OMG OMG OMG OMG! MAN YOU ARE AMAZING! I just pasted it on a fresh new launcher copy - launcher3.ini - and it works like a charm! I only have to adjust and resize a bit the image to make it look more...well..."human" in the eye..haha. We can try that tomorrow or any time you can, dude, you really helped me greatly! I don't know how to repay you and Balala...I feel bad actually..

Don't feel bad, it was a pleasure. I won't say more of that though, so I won't win your heart...again
So, what you want me to do next? Resize the button image (specify the W and H) or split it in 3 and use resizable image meters instead of a button? Or both?

[Yincognito]

No, you can't through the W and H options, but you can using a TransformationMatrix. For example in this case adding a TransformationMatrix=0.5;0;0;0.5;9;27 option to the [MT_Launcher_Button] meter, you'll get the button resized to half of its initial size.
This is one reason why I say TransformationMatrix is an extraordinary powerful option. Probably not too easy to be used, but very powerful.

I know about TransformationMatrix and recently learned to work with it pretty well (I made a fork of a skin for someone and turned it into a horizontally adaptive one according to the numbers of items shown, by using the option, you can check it here)...but doesn't the manual say that "All general meter options are valid, except W, H and TransformationMatrix." on the Button meter? See, that's why I never mentioned TransformationMatrix in this case...

Or maybe I didn't correctly understood what the manual said?!

[jsmorley]

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, as well as relative positioning of subsequent meters.
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.
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. My goal would be to reduce the need for TransformationMatrix to some very obscure "skew" capabilities, and try hard to forget about it.

[Yincognito]

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...

[jsmorley]

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.

It's certainly not going to go away. My goal would be to have simpler alternative(s) that might be favored by the average, and particularly new, skin author, but TransformationMatrix will always be available. It just can't be "fixed / changed" due to backwards compatibility issues. It is what it is.

[Yincognito]

It's certainly not going to go away. My goal would be to have simpler alternative(s) that might be favored by the average, and particularly new, skin author, but TransformationMatrix will always be available. It just can't be "fixed / changed" due to backwards compatibility issues. It is what it is.

Good to know. What do you think about the NOTE on my last reply? Is it doable in Rainmeter's source code or not? Not trying to push anything, I'm just asking.

EDIT: Nevermind, I realized that what I said was already happening. Don't bother answering to my NOTE, it won't solve things.

[jsmorley]

Good to know. What do you think about the NOTE on my last reply? Is it doable in Rainmeter's source code or not? Not trying to push anything, I'm just asking.

A meter, by its very nature, is always going to be a square or rectangle defined entirely by W and H. There is simply no way to ever "rotate" or "skew" a meter. You can only rotate or skew the "contents" of the meter. So the key to better behavior is going to be having mouse detection be on the "content" of the meter, rather than on the "meter" as it is in most cases today. Button and Shape being notable exceptions. That still won't solve some relative positioning issues, but would be a vast improvement. Having said that though, we still always need to consider backwards compatibility, and that means we have to carefully think through how we approach this.

Nothing is going to happen with this in Rainmeter 4.3, as that is nearing release. We will likely be taking a hard look at "scaling" and "rotating" in the next version of Rainmeter. This is likely to mean some "new" options, in order to maintain backwards compatibility.

In any case, the fact that currently TransformationMatrix is the "only" alternative for some of this doesn't in my view make it a "good" alternative. I actually despise it...

[Yincognito]

A meter, by its very nature, is always going to be a square or rectangle defined by W and H. There is simply no way to ever "rotate" or "skew" a meter. You can only rotate or skew the "contents" of the meter. So the key to better behavior is going to be having mouse detection be on the "content" of the meter, rather than on the "meter" as it is in most cases today. That still won't solve some relative positioning issues, but would be a vast improvement. Having said that though, we still always need to consider backwards compatibility, and that means we have to carefully think through how we approach this.

Nothing is going to happen with this in Rainmeter 4.3, as that is nearing release. We will likely be taking a hard look at "scaling" and "rotating" in the next version of Rainmeter. This is likely to mean some "new" options, in order to maintain backwards compatibility.

But doesn't the ButtonCommand option in the Button meter already doing this? You know, since the manual states that it ignores the transparent pixels at all times. In my view, this means that mouse detection is done on the "content" of the meter, and not on its "rectangle". Something like this could be done in the plans you mentioned.

What I meant in my note (but wrongly phrase it) is that TransformationMatrix could "retain" the meter's updated coordinates of its four corners (and potentially pass those to the X,Y,W and H options for skin developers to use). But yeah, this affects backwards compatibility, so, in the end, you are right on this...

[jsmorley]

But doesn't the ButtonCommand option in the Button meter already doing this? You know, since the manual states that it ignores the transparent pixels at all times. In my view, this means that mouse detection is done on the "content" of the meter, and not on its "rectangle". Something like this could be done in the plans you mentioned.

What I meant in my note (but wrongly phrase it) is that TransformationMatrix could "retain" the meter's updated coordinates of its four corners (and potentially pass those to the X,Y,W and H options for skin developers to use). But yeah, this affects backwards compatibility, so, in the end, you are right on this...

Yes, Button and Shape both detect the mouse only on solid pixels of the "content" of the meter, and not the meter itself. We can't just slam that into all other existing meters though, as tons of existing skins would break. Button was always like that, and Shape was "new", so we had some flexibility. We also play some tricks with the "new" Container option, so the mouse is only detected on solid pixels of the "content", AND only on the part of that content that is "inside" the container.

[Yincognito]

In any case, the fact that currently TransformationMatrix is the "only" alternative for some of this doesn't in my view make it a "good" alternative. I actually despise it...

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.