Yes I understand the implementation is complicated at the moment. Certainly you simulated the window resizing ability, but I am just questioning the implementation of the resize feature directly into the Rainmeter.Jax wrote: ↑July 29th, 2022, 3:29 pm It is viable!
Bottom.gif
But unfortunately, what it is doing right now isbut optimally, it should be
- checking for mouse pos
sends bangs
bang: change skin content sizes
bang: redraw
changes window size (DynamicWindowSize=1
- changes window size
sends optional bangs (redraw contents etc.)
Pretty sure a skin window is just like any other skin window, with it's property changed to hide it's title bars and such. Might be wrong though
I might be wrong, but try to look inside out. There sure is some sort of "canvas" and there are even some options that contain the word "window" like DynamicWindowSize. But what Rainmeter does is first it reads a skin and then draws the meters on every redraw which consequently makes up the window. At the beginning there is certainly a canvas where meters are drawn, but from what I understand, the "window" is formed after the meters are drawn. Thus, you don't start with a window, the window is formed after the meters are drawn and dynamically reshaped after the meters are redrawn. In this manner, the meters control the dynamic window size. Also, since by default you don't need to specify any boundaries or a window to a skin, it means that Rainmeter is not dependent on the whole window concept. These are why the skin "window" is not like any other window.
https://forum.rainmeter.net/viewtopic.php?t=23675#p126084
https://forum.rainmeter.net/viewtopic.php?t=20773&start=10#p110916
Well, this is just one of my assumptions, but let's see what else we have.
Let's assume that there are some resizing GDI/D2D libraries or Windows elements (like InputText) that could be either directly integrated into Rainmeter as an option or integrated in the form of a plugin (like, again, InputText). In such case, it would probably be possible to move forward by improving the BackgroundOptions to support the resizing. It already has some good fundamental things for resizing but also some bad sides that don't logically allow the resizing:
• Good: when a custom Background in [Rainmeter] is defined, changing SkinWidth/SkinHeight in [Rainmeter] would also resize the Background.
• Bad: meters can't be positioned relatively to the SkinWidth/SkinHeight.
• Bad: declaring SkinWidth/SkinWeight would disable DynamicWindowSize which is needed for the resizing ability.
From this, I can conclude that it would be possible to make a resizable and "responsive" if BackgroundOptions are improved to support the resizing, essentially by:
- integrating some resizing code/library to support Background resize with a mouse,
- making SkinWidth/SkinHeight dynamic,
- adding options to resize SkinWidth/SkinHeight
- allowing meters to be positioned relatively to SkinWidth/SkinWeight (for example: X=[Rainmeter:W]),
- expanding it further to make the resizing "fluid" by making this option to quickly update Rainmeter just like ActionTimer does this (or making it compatible with ActionTimer).
Other options that could allow resizing:
- A better or an official dragging plugin which will nicely tackle both the meter dragging and resizing.
- A new Window meter which will work similarly to Image meter but will act as a real window by having a set of options that will allow this meter to be nicely resized by mouse plugin. Having it as a meter would allow other meters to be placed/resized relatively to this new meter. However, I think this solution doesn't sound as nice and logical as improving BackgroundOptions which already has Background option that sort of simulates the window.