It is currently December 5th, 2022, 3:02 pm

[Feature] Directly incorporate window resizing to skin window

Report bugs with the Rainmeter application and suggest features.
User avatar
Jax
Posts: 104
Joined: June 7th, 2021, 11:46 am

[Feature] Directly incorporate window resizing to skin window

Post by Jax »

Currently skin configuration windows like JaxCore and VectorConverter use clever ways (credit to azack) to make them resizable like a normal window, however it still misses feature like snapping to the grid and responding to Window's window manager. I am hoping for an option optimally in the Rainmeter section would enables window snapping, and have a measure similar to actiontimer's separate clock which updates whenever the window is resized. Let me know if you have any questions! :thumbup:
User avatar
Yincognito
Rainmeter Sage
Posts: 4817
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature] Directly incorporate window resizing to skin window

Post by Yincognito »

This one is easy (well, not so easy if you already started the classic way) and does need any clever hack solution: just make your skins scalable from the start, via a mouse scroll or resizing the base font, and everything would snap to whatever you need afterwards, like the usual.

All my skins are designed to be scalable, even my WebView plugin based JavaScript globe (and the plugin developer did not made the web window scalable in realtime in that case!), so I know for a fact that it works. 8-)
User avatar
Active Colors
Moderator
Posts: 1199
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany

Re: [Feature] Directly incorporate window resizing to skin window

Post by Active Colors »

Yincognito wrote: July 27th, 2022, 8:16 am This one is easy (well, not so easy if you already started the classic way) and does need any clever hack solution: just make your skins scalable from the start, via a mouse scroll or resizing the base font, and everything would snap to whatever you need afterwards, like the usual.

All my skins are designed to be scalable, even my WebView plugin based JavaScript globe (and the plugin developer did not made the web window scalable in realtime in that case!), so I know for a fact that it works. 8-)
He asks to implement the resizing by mouse dragging, like in the actual window where through dragging window's edges you resize the window.

It is quite difficult to implement this feature in my opinion. The whole skin canvas architecture would need to be redone for the sake of this feature.

I think for now it is viable to do via MouseXY plugin and ActionTimer.

I have also seen the author who made a custom Autoit app to make his skins resizable. It worked really well but due to the nature of Autoit it is not the best solution.

I think the most logical solution would be to develop a plugin that would achieve this. Preferably an official plugin which would incorporate a temporary fast update/redraw rate and the mouse XY detection, and custom action on the dragging.
User avatar
Yincognito
Rainmeter Sage
Posts: 4817
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature] Directly incorporate window resizing to skin window

Post by Yincognito »

Active Colors wrote: July 27th, 2022, 9:32 am He asks to implement the resizing by mouse dragging, like in the actual window where through dragging window's edges you resize the window.

It is quite difficult to implement this feature in my opinion. The whole skin canvas architecture would need to be redone for the sake of this feature.

I think for now it is viable to do via MouseXY plugin and ActionTimer.

I have also seen the author who made a custom Autoit app to make his skins resizable. It worked really well but due to the nature of Autoit it is not the best solution.

I think the most logical solution would be to develop a plugin that would achieve this. Preferably an official plugin which would incorporate the temporary fast update/redraw and the mouse XY detection, and custom action on the dragging.
Yeah, I suspected that's what he wanted. The mouse cursor can easily be changed to a <-> style in Rainmeter, only the position and the ability to do this on drag would be required (the skins margins would have to be adjusted accordingly in Rainmeter on "focus", if he wants that "feature" as well). For the latter two, I believe, like you said already, that the MouseXY plugin checks both of those, if my memory serves.

I see no reason to develop a plugin for something that's already doable without any major or obvious drawbacks using the current set of Rainmeter plugins, but if you ask me, I would make the MouseXY features part of the official Rainmeter distribution (either by incorporating them in the code directly or by making the plugin an official one). There could be some reasons why that didn't happen yet, though. :???:
User avatar
Active Colors
Moderator
Posts: 1199
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany

Re: [Feature] Directly incorporate window resizing to skin window

Post by Active Colors »

Yincognito wrote: July 27th, 2022, 11:45 am Yeah, I suspected that's what he wanted. The mouse cursor can easily be changed to a <-> style in Rainmeter, only the position and the ability to do this on drag would be required (the skins margins would have to be adjusted accordingly in Rainmeter on "focus", if he wants that "feature" as well). For the latter two, I believe, like you said already, that the MouseXY plugin checks both of those, if my memory serves.

I see no reason to develop a plugin for something that's already doable without any major or obvious drawbacks using the current set of Rainmeter plugins, but if you ask me, I would make the MouseXY features part of the official Rainmeter distribution (either by incorporating them in the code directly or by making the plugin an official one). There could be some reasons why that didn't happen yet, though. :???:
I agree that it is almost the time to consider making the mouse plugins' features to be native.

I think it could be even possible to introduce them as the new mouse bangs, similarly to the bangs from this plugin https://forum.rainmeter.net/viewtopic.php?t=26030
• MouseMoveAction
• LeftMouseDragAction
• RightMouseDragAction
• MiddleMouseDragAction

And they might even work in combination with ActionTimer to make fluid changes (for example, a slider with the drag'able knob). They can also utilize already available mouse variables.

But then, if you would want a fluid skin, those bangs would somehow need to handle the fast update rate like the ActionTimer plugin. Maybe these bangs could work in combination with ActionTimer to make the fluid changes. But I am not sure about any negative consequences.

For the sake of simplicity, maybe there could be a plugin that would do something similar to this:
GIF 27.07.2022 16-06-51.gif

By the way.
What I like about that plugin is that it does not require a skin to have a fast update rate to make fluid changes (works same as ActionTimer). But what I don't like about that plugin is that it has never properly worked for me - it is fluid for couple of seconds but then it starts to continuously stutter and glitch.
What I like about this plugin https://forum.rainmeter.net/viewtopic.php?t=22900 is that it does not stutter or glitch. But it is very simple, and therefore it doesn't have the ability to temporarily switch to the fast update rate mode like that plugin above or like ActionTimer. Maybe this plugin coupled with ActionTimer can achieve the desired results (e.g. in making the drag'able slider) but I haven't tried that out yet.

Those who might want to create a better mouse plugin they might want to dissect these plugins too:
https://forum.rainmeter.net/viewtopic.php?t=23107
https://forum.rainmeter.net/viewtopic.php?t=20773
You do not have the required permissions to view the files attached to this post.
User avatar
Yincognito
Rainmeter Sage
Posts: 4817
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature] Directly incorporate window resizing to skin window

Post by Yincognito »

Active Colors wrote: July 27th, 2022, 1:45 pmBut then, if you would want a fluid skin, those bangs would somehow need to handle the fast update rate like the ActionTimer plugin. Maybe these bangs could work in combination with ActionTimer to make the fluid changes. But I am not sure about any negative consequences.
Very nice post, with very informative links and previews! It will surely be useful one way or another to anyone reading this, including Jax. Me, I'm not that good with searching for Rainmeter plugins on the forum, but thanks to guys like you and others, I've been able to find out about some of them.

On the fluidity needed for stuff like this to work smoothly, unless handling the mouse needs some extra processing power and such, or resizing the skin like that also involves resizing / redrawing big images, animations and so on (which will CERTAINLY use significant CPU power, depending on quantity and quality), I can guarantee that for relatively simpler cases will work flawlessly. In my skins, I prefer setting the skin update rate method over ActionTimer due to very minor resource usage differences between them, but when designing my custom tooltips system I noticed that stuff works in a fluid way even when making the tooltips "follow" the main skin at a couple of milliseconds update (settled on a 1 second update rate though).

Now of course, both my skins and my tooltips are small and simple enough (at least on a first look, LOL) to work this way (I only have one icon sized image in the tooltip), but having them work nice at the same time with animations going on in my skins is an indication that what you said has the potential to have very few - if any - negative consequences. The problem is like I said, that for a drag and drop resize on a skin, one would need to redimension and redraw all its elements, and depending on how efficient, many or large those are, some slowing down and such might occur, especially if the CPU is already busy with something else in another programs. You know, there's a good reason for the system in your preview only showing the redimensioned frame before eventually redrawing all the "window" contents ... because the latter can sometimes be quite expensive.

Basically, if a skin doesn't consume much when scaling it the "normal" / automatic way in a Calc counter or similar, then it will work the same in a mouse drag and drop system like you described and envisioned, because the only difference would be the mouse involvement and skin position changing. Regarding efficiency, you can't imagine (or maybe you can) how small are the details to make a skin be minimal in terms of resource usage. In some cases I spent days looking for ways to lower down the resource usage (which wasn't even that high in the first place, since it's Rainmeter, but you know me, always looking for the best scenario, LMAO), only to find out all it took was some value being set somewhere and making the process as compact and linear as possible.
User avatar
Active Colors
Moderator
Posts: 1199
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany

Re: [Feature] Directly incorporate window resizing to skin window

Post by Active Colors »

Yincognito wrote: July 27th, 2022, 3:38 pm Very nice post, with very informative links and previews! It will surely be useful one way or another to anyone reading this, including Jax. Me, I'm not that good with searching for Rainmeter plugins on the forum, but thanks to guys like you and others, I've been able to find out about some of them.

On the fluidity needed for stuff like this to work smoothly, unless handling the mouse needs some extra processing power and such, or resizing the skin like that also involves resizing / redrawing big images, animations and so on (which will CERTAINLY use significant CPU power, depending on quantity and quality), I can guarantee that for relatively simpler cases will work flawlessly. In my skins, I prefer setting the skin update rate method over ActionTimer due to very minor resource usage differences between them, but when designing my custom tooltips system I noticed that stuff works in a fluid way even when making the tooltips "follow" the main skin at a couple of milliseconds update (settled on a 1 second update rate though).

Now of course, both my skins and my tooltips are small and simple enough (at least on a first look, LOL) to work this way (I only have one icon sized image in the tooltip), but having them work nice at the same time with animations going on in my skins is an indication that what you said has the potential to have very few - if any - negative consequences. The problem is like I said, that for a drag and drop resize on a skin, one would need to redimension and redraw all its elements, and depending on how efficient, many or large those are, some slowing down and such might occur, especially if the CPU is already busy with something else in another programs. You know, there's a good reason for the system in your preview only showing the redimensioned frame before eventually redrawing all the "window" contents ... because the latter can sometimes be quite expensive.

Basically, if a skin doesn't consume much when scaling it the "normal" / automatic way in a Calc counter or similar, then it will work the same in a mouse drag and drop system like you described and envisioned, because the only difference would be the mouse involvement and skin position changing. Regarding efficiency, you can't imagine (or maybe you can) how small are the details to make a skin be minimal in terms of resource usage. In some cases I spent days looking for ways to lower down the resource usage (which wasn't even that high in the first place, since it's Rainmeter, but you know me, always looking for the best scenario, LMAO), only to find out all it took was some value being set somewhere and making the process as compact and linear as possible.
Yes I understand that once a wheel is invented, the spaceship will follow. If you let users make simple dragable sliders......
User avatar
Yincognito
Rainmeter Sage
Posts: 4817
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature] Directly incorporate window resizing to skin window

Post by Yincognito »

Active Colors wrote: July 27th, 2022, 6:55 pm Yes I understand that once a wheel is invented, the spaceship will follow. If you let users make simple dragable sliders......
Haha, yeah - very funny analogy. I'm all for spaceships and letting the users fly on top of their sliders though - everything has a solution eventually... 8-)
User avatar
Jax
Posts: 104
Joined: June 7th, 2021, 11:46 am

Re: [Feature] Directly incorporate window resizing to skin window

Post by Jax »

Active Colors wrote: July 27th, 2022, 9:32 am

He asks to implement the resizing by mouse dragging, like in the actual window where through dragging window's edges you resize the window.

It is quite difficult to implement this feature in my opinion. The whole skin canvas architecture would need to be redone for the sake of this feature.

I think for now it is viable to do via MouseXY plugin and ActionTimer.

I have also seen the author who made a custom Autoit app to make his skins resizable. It worked really well but due to the nature of Autoit it is not the best solution.

I think the most logical solution would be to develop a plugin that would achieve this. Preferably an official plugin which would incorporate a temporary fast update/redraw rate and the mouse XY detection, and custom action on the dragging.
It is viable!
Bottom.gif
But unfortunately, what it is doing right now is
  • checking for mouse pos
    sends bangs
    bang: change skin content sizes
    bang: redraw
    changes window size (DynamicWindowSize=1
but optimally, it should be
  • changes window size
    sends optional bangs (redraw contents etc.)
that way, the skin contents can clip without the window resizing, and the current method is actually resulting in a slower and (relatively more, notible when comparing with a standard window) unresposive experience

I've also seen sliders mentioned here, I think sliders should remain the way as they are right now, created by multiple meters and plugins for this component.

The reason for the suggestion is for snapping to the grid and responding to Window's window manager, since these are direct properties of the skin window.
The whole skin canvas architecture would need to be redone for the sake of this feature.
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
You do not have the required permissions to view the files attached to this post.
User avatar
Yincognito
Rainmeter Sage
Posts: 4817
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature] Directly incorporate window resizing to skin window

Post by Yincognito »

Jax wrote: July 29th, 2022, 3:29 pmBut unfortunately, what it is doing right now is
  • checking for mouse pos
    sends bangs
    bang: change skin content sizes
    bang: redraw
    changes window size (DynamicWindowSize=1
but optimally, it should be
  • changes window size
    sends optional bangs (redraw contents etc.)
that way, the skin contents can clip without the window resizing, and the current method is actually resulting in a slower and (relatively more, notible when comparing with a standard window) unresposive experience

I've also seen sliders mentioned here, I think sliders should remain the way as they are right now, created by multiple meters and plugins for this component.

The reason for the suggestion is for snapping to the grid and responding to Window's window manager, since these are direct properties of the skin window.
So basically you want what Active Colors illustrated above, i.e. the skin's "frame" changing its "virtual" size flawlessly on drag, before the rest of the operations (i.e. changing content sizes, changing the actual skin's size and redrawing) take place when eventually releasing the mouse button, right? If I understand correctly what you want, it is doable via a second skin which would act like a "frame" of the main skin, so that you can "preview" how big the result will be before you release the button and let the heavy operations take place only once. Of course, that second skin would have to have the same position, initial dimensions as the main skin, and only be shown while dragging, with it hiding on the drag end event.

Unfortunately for your case, if I'm not missing something, the Rainmeter skin snapping to other skins only acts when the skin is dragged by the user, and not on redimensioning the skin, as can be seen below, where my "screen ruler" skin on the left changes its size unrestricted, before snapping to my rotating Earth WebView skin on the right only when I drag it entirely myself with the mouse:
ezgif.com-gif-maker.gif
ezgif.com-gif-maker (1).gif
Jax wrote: July 29th, 2022, 3:29 pmPretty 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
Yes, it's something along those lines, but not entirely. Its size, behavior and appearance aren't controlled by Windows bar a very basic level, but by Rainmeter. A skin is more or less an image drawn over a window "container". Snapping to other windows in Windows, for example, or to the edges of the screen in order to snap layout or however that is called in Windows, won't produce the same results as for other windows.
You do not have the required permissions to view the files attached to this post.