Any better solution for snappable skin margins on a dynamic dimension skin?

[Crest]

For some time it has seemed to me the only feasible method of setting snappable margins for inter-skin/screen area for dynamic width/height skins is to include invisible meters that act as such around each skin.

However this has the drawback as illustrated below, where adjacent/flush other skins double-up the margins. This means one has to reduce the meter-based margin dimensions by half to compensate.

Example.png

However that has two downsides of its own:

• When snapping to outermost edges of screen/monitor area the margin will be half, rather than the desired 'full' margin (ie: there's a discrepancy between the skin margin and the user-expected margin against the screen edges)
• Any effects one may want to apply within the pseudo-margin area, like shadows, then requires reduction (if necessary) to fit within the adjusted half-size margins.

The first issue I could foresee being mitigated two ways: either try to clamp the skin coords to within a certain boundary of the screen at all times (haven't tested any PoC for how this would interact with user moves via dragging), or have some separate invisible skin that wraps around the screen edges to act as the complementary second-half of the margin.

While the second issue is more one that I can't foresee any mitigation for, since fundamentally afaik Rainmeter doesn't really have a way to treat visible areas around a skin separate from desired bounds (unlike say CSS' box model or Windows' windows with their shadows, etc), so whatever in the skin is physically consuming dimensions becomes part of the skin's snappable point.

Have I overlooked any other methods? Is there a way to create separate snapping bounds from the skin bounds?

(Of course the other aspect is even if they could snap closer together any peripheral effects like shadows may overlap depending on z index, but let's say for the sake of it such shadows only appear on mouse over)

[SilverAzide]

I've been asking myself this question for at least the last 10 years of using Rainmeter. I think the answer to your question is simply "No". I suspect the only way this could be handled is if Rainmeter itself implemented an "auto-arrange" feature that handled margins, like the old Windows Sidebar gadgets did. I don't see that ever happening.

That said, the only other solution I can think of is for you to make your skins "screen-edge" aware. The problem with the margins, as shown in your diagram, is only a problem when you get to the edges of the screen. You could easily calculate if your skin is at a screen edge and, if so, add an additional 1/2 margin spacing on that side.

[Yincognito]

Have I overlooked any other methods? Is there a way to create separate snapping bounds from the skin bounds?

Well, assuming your "margins" will eventually be of the near transparent 0,0,0,1 solid color, you could try:
- https://docs.rainmeter.net/manual/skins/rainmeter-section/#DragMargins (in [Rainmeter])
- https://docs.rainmeter.net/manual/meters/general-options/#Padding (in the background meter)
but they will have the same "drawback" of "halving" at the outer edges of the skin arrangement.

One way to deal with the said drawback (which I personally don't mind in either the skin arrangement on the screen or the meter arrangement in the skin, since if you think about it, it's kind of logical), assuming you know the "anchor" / "reference point" for the arrangement, would be to only use these "margins" in the direction of that anchor point. For example, if you align your skins starting from the top left of your screen, you could use those near transparent margins only on the top and left side of your skins, since the top and left side of the following skin will suffice as the margin for the right and bottom side of the current skin. Obviously, in this variant, the last skins in the arrangement will lack a margin, but then, if nothing comes after them, why bother anyway? Another particularity of this approach is that it doesn't suit the case where you don't know where that arrangement anchor will be.

There might be some other ways I can't think of right now though...

[Crest]

While the second issue is more one that I can't foresee any mitigation for, since fundamentally afaik Rainmeter doesn't really have a way to treat visible areas around a skin separate from desired bounds (unlike say CSS' box model or Windows' windows with their shadows, etc), so whatever in the skin is physically consuming dimensions becomes part of the skin's snappable point.

Just putting this idea out there since I don't think it's entirely feasible with Rainmeter currently but one could add shadows that extend beyond the primary skin by using a second skin that auto aligns to it. Effectively creating a separate bounding box.

The issues with that would be:

• There's no way (afaict) to query Rainmeter for the skin's current dynamic Z index (such as occurs when two skins overlap and one is clicked, changing its Z index to overlap the other). Only the major static Z positions like On Desktop/Normal/Topmost can be changed. This has the upshot of the secondary shadow skin not having insight into how it should overlap when intersecting with (or being directly adjacent to, wrt to self-shadow overlap) other skins.
• Unclear how feasible moving both skins simultaneously and seamlessly would be. One mitigation could be for a skin to send the shadow skin info when its coordinates move and to hide it until movement has ended but without a proof of concept idk how well this would work in practice.
• Would require the secondary skin at least has Keep On Screen disabled to prevent misalignment at monitor edges. Can't recall if this setting is adjustable via code.

[Yincognito]

The issues with that would be:

[*] Unclear how feasible moving both skins simultaneously and seamlessly would be. One mitigation could be for a skin to send the shadow skin info when its coordinates move and to hide it until movement has ended but without a proof of concept idk how well this would work in practice.

There's no (dynamic) OnMoveAction option in [Rainmeter] to detect when a skin moves, so you'd have to use a low Update in your main skin and the lower the update, the more seamless the movement will be (won't be real-time though). I don't think you'd need to bother with the Z order too much, just simply move the shadow skin first and then "zero move" the main skin to keep it focused and "in front" of the shadow skin.

No need to complicate it though, this is perfectly / easily doable using just the main skin, you only need to detect if any of the coordinates of the skin is either the lowest or the highest in the skin arrangement (i.e. if it's at the edges of the arrangement), and correspondingly double those margins, like SilverAzide mentioned.

[Crest]

I don't think you'd need to bother with the Z order too much, just simply move the shadow skin first and then "zero move" the main skin to keep it focused and "in front" of the shadow skin.

Wouldn't moving by the shadow skin first necessitate it being the top-most clickable element? That is, if one wanted to just grab the skin arbitrarily. If the main skin had interactive buttons then the shadow skin would need to only appear around the edges of the skin (and ideally not be interactable with the mouse at all).

Just to clarify (so I know we're talking about the same thing), part of the problem is when two skins overlap and the user clicks on one or the other and it's then raised above the other skin, despite both being ostensibly on the same 'main' Z position (ie: both could be on the 'Normal' or 'Topmost' position but Rainmeter still allows for dynamic overlap/Z-index within that, depending on which skin was last focused).

For the dual skin idea to work it would have to have insight into that dynamic Z-index, which IIRC last I searched wasn't possible to detect. Otherwise what would occur when a skin overlapped would be the shadow skin would be left in its original Z-index and the main skin would lose its apparent shadow on the part that intersects/overlaps the other skin (also for the sake of example, assuming no skin moves, only static clicks to focus either skin).

That said the scenario where non-overlapping shadows is actually very beneficial is when skins are intended to be snapped side-by-side, since one expects that the shadows would be the bottom-most z-index compared to the skins else either skin shadow would overlap the other skin (if large enough). This would get tricky to determine snapped positions vs non-snapped overlaps. It'd still need insight into z-index though since otherwise if one clicked a skin above say a non-Rainmeter window it would raise the main skin but not its shadow.

No need to complicate it though, this is perfectly / easily doable using just the main skin, you only need to detect if any of the coordinates of the skin is either the lowest or the highest in the skin arrangement (i.e. if it's at the edges of the arrangement), and correspondingly double those margins, like SilverAzide mentioned.

This bounding box aspect was just a separate consideration to the doubled margin part of the OP (since any narrowed margins means less room for such effects). Basically if someone wants to snap two skins together, while having peripheral effects like shadows extend beyond where they'd like the snap margins to be, it's impossible normally since Rainmeter treats any part of the skin that has a meter at the edges part of the bounding box for snapping.

The idea I posted above is just a workaround for having separate snappable area vs the visual extremities of the skin. See the illustration below, picturing two skins where you want them to snap together at the shown distance. The red lines represent the actual skin bounds that Rainmeter would snap to ordinarily if the shadows were part of each blue skin shown (rather than a separate skin).

Shadows explanation.png

[Yincognito]

Wouldn't moving by the shadow skin first necessitate it being the top-most clickable element?

No, because its movement would be from the main skin's code, with the manual dragging only on the main skin. Also, I assumed that both skins would have the same Normal display (since Topmost will make them "fight" each other for the top spot, resulting in blinking and such).

Just to clarify (so I know we're talking about the same thing),
[...]
the main skin would lose its apparent shadow on the part that intersects/overlaps the other skin
[...]
Basically if someone wants to snap two skins together, while having peripheral effects like shadows extend beyond where they'd like the snap margins to be, it's impossible normally since Rainmeter treats any part of the skin that has a meter at the edges part of the bounding box for snapping.

There's a bit of disconnection between what we're talking about, since there's not yet any code involved to make things perfectly clear. In what I talked about, there's no skin overlap at all (besides the main vs shadow skin scenario, of course): the shadows would be drawn between the snap margins and the actual / blue part of the skin, so snapping would occur where the shadows end. There's no need for shadows to extend beyond the snap margins between the skins in the single skin scenario, since the overlapping parts of the shadows would not be visible anyway, so the shadow / snap margin can correspondingly be narrowed / darkened between skins.

I think the best thing here would be to have some minimal code for let's say 9 identical skins like in your last screenshot, so that stuff becomes clearer. I'm not at my laptop now, but I suppose the shadow Image / gradient and the rounded blue rectangle Shape is all such sample skins would contain...

[Crest]

In what I talked about, there's no skin overlap at all (besides the main vs shadow skin scenario, of course): the shadows would be drawn between the snap margins and the actual / blue part of the skin, so snapping would occur where the shadows end. There's no need for shadows to extend beyond the snap margins between the skins in the single skin scenario, since the overlapping parts of the shadows would not be visible anyway, so the shadow / snap margin can correspondingly be narrowed / darkened between skins.

If I'm understanding what you've written here it seems what's being described is a different scenario than what I've illustrated, where all shadows are instead narrowed to fit within the snap margins of the skin, in which case there doesn't need to be a separate shadow skin as it can just be part of the main skin as a meter.

Whereas my conceptual post above (and partly touched on in OP) was about shadows (or anything else) that are desired to extend beyond the snappable margins, as a workaround for Rainmeter's limitation of treating any meters in one skin as extending the skin's bounds (so in the illustration above if the shadows were part of each two skins Rainmeter would snap to the edges of the large shadows instead of the desired narrower margin).

The overlap discrepancy I was describing with the z-index is illustrated via the following:

Shadows explanation - Overlap animation.gif

I think the best thing here would be to have some minimal code for let's say 9 identical skins like in your last screenshot, so that stuff becomes clearer. I'm not at my laptop now, but I suppose the shadow Image / gradient and the rounded blue rectangle Shape is all such sample skins would contain...

Tbh I haven't made any code since I didn't think it was feasible with the downsides described for the concept illustrated.

[Yincognito]

If I'm understanding what you've written here it seems what's being described is a different scenario than what I've illustrated, where all shadows are instead narrowed to fit within the snap margins of the skin, in which case there doesn't need to be a separate shadow skin as it can just be part of the main skin as a meter.

Exactly. That's the simplest and most effective approach.

Whereas my conceptual post above (and partly touched on in OP) was about shadows (or anything else) that are desired to extend beyond the snappable margins, as a workaround for Rainmeter's limitation of treating any meters in one skin as extending the skin's bounds (so in the illustration above if the shadows were part of each two skins Rainmeter would snap to the edges of the large shadows instead of the desired narrower margin).

Well, you can temporarily hold CTRL if you really want a skin to not snap at its (partly or fully) opaque meters' margins (which is how snapping works in Rainmeter), see Snap To Edges and Load Order here:
https://docs.rainmeter.net/manual/arranging-skins/
Not sure if that helps, but maybe can spur some ideas, I don't know.

The overlap discrepancy I was describing with the z-index is illustrated via the following:

Forget about the double skin (main and shadow) scenario, you're overcomplicating things and add unnecessary obstacles to the process. In case you really want to think about it, you can take a look at how a custom tooltip "follows" the main skin here (you probably don't need most of that, but just to get the idea, it's just about a !Move bang while skins are communicating positions between them via !SetVariable bangs with a Config parameter):
https://forum.rainmeter.net/viewtopic.php?t=34759

Tbh I haven't made any code since I didn't think it was feasible with the downsides described for the concept illustrated.

Well, beginning with conceptualizing the thing does help, but without actually trying you can't be aware of what exactly is feasible / possible. Just an example, you can untick Snap To Edges entirely and make your own snapping process via !Move or !SetWindowPosition as per your needs, assuming you know which skins are active at any given time.

[Yincognito]

Whereas my conceptual post above (and partly touched on in OP) was about shadows (or anything else) that are desired to extend beyond the snappable margins
[...]
Tbh I haven't made any code since I didn't think it was feasible with the downsides described for the concept illustrated.

Well, since nobody else bothered with a code, here's a severely unpolished basic sample of a 9 identical skin suite, which on mouse hover uses shadows 10px wide in order to snap at those, followed by extending the shadows to 20px on mouse leave, i.e. after the snap occured:

Snap_1.0.0.rmskin

Snap.jpg

In the code, L means last margin, C means current margin, where margin is the space from where the main area (aka the Master meter) ends to where the margin area (aka the Shadow meter) ends. Current drawbacks, to be solved if desired by someone else: "blinking" when the mouse goes from the main area to the margin area (logical in the current state of the implementation, since the position and size of the skins change on hover/leave, along with the hovered area itself). The "shadows" are rudimentar, of course, just to illustrate the idea.