space between skins

[balala]

And there is no way this can be done.

Right!

[CodeCode]

Euclidean physics are beyond Rainmeters capacity.

[sl23]

He is moving a skin using !Move and there is a possibility that it may overlap with another skin. He doesn't want that to happen. And there is no way this can be done.

How did you pick that up from his post???

Ok, I'll leave this to the pro's!

[death.crafter]

How did you pick that up from his post???

Ok, I'll leave this to the pro's!

if i move a skin it automaticly see with it collides with another skin.
i want to know how to keep space between those skin.

He can't possibly mean moving the skin manually.

[CodeCode]

He can't possibly mean moving the skin manually.

Right. Rainmeter does not in any way provide leeway for user input vs programmatic actions.to move things that is

[Yincognito]

Oh man, one of the things I just can't agree with is when folks say something is "impossible" or it can't be done, just because it's the easy way out of a tricky question, LOL. Nothing is impossible, if the tools for making it possible exist.

This is true for this case too, irrespective if the movement is user or programmatic initiated. The only difference between the two is that for the former, temporary collision is PROBABLY a given, at least until the user releases the mouse button used for dragging. Even then, it might be possible to circumvent that too, but I can't test it ATM.

Basically, it's all about pasting passing the current config's X, Y, W, H of the other skins to the skin that is intended not to collide with others, then in this skin doing some (complex, I admit) math to move it back to a place where it doesn't collide with any other (if such a place exists, of course). This probably won't be doable in realtime, but will be doable nevertheless.

So, the real answer to the OP's question is not that it's impossible, but rather that it's quite complicated to do and probably not worth the effort. Much easier to just use your fingers if the movement is user initiated, or set up a rectangular "valid" area on which the skin can move and be done with it.

[death.crafter]

Oh man, one of the things I just can't agree with is when folks say something is "impossible" or it can't be done, just because it's the easy way out of a tricky question, LOL. Nothing is impossible, if the tools for making it possible exist.

Scenario:

• 1- The skin is related to user's current skin

• 2- The skin is random

Event:

• a- User wants the other skin to move wrt the current skin

• b- User wants to move the other skin only if the current skins overlaps it.

Now:

• - 1.a has a 100% possibility

• - 1.b is outright impossible since there is no way you can know if they are overlapping

• - 2.a needs tinkering of the other skin

• - 2.b is same as 1.2

But:

• P<"scenario 1"> = 1/2, and

• P<case "a">≈0

So:

• Possibility of the event tends to 0.

Conclusion:

• It is impossible.

[Yincognito]

Scenario:

• 1- The skin is related to user's current skin

• 2- The skin is random

Event:

• a- User wants the other skin to move wrt the current skin

• b- User wants to move the other skin only if the current skins overlaps it.

Now:

• - 1.a has a 100% possibility

• - 1.b is outright impossible since there is no way you can know if they are overlapping

• - 2.a needs tinkering of the other skin

• - 2.b is same as 1.2

But:

• P<"scenario 1"> = 1/2, and

• P<case "a">≈0

So:

• Possibility of the event tends to 0.

Conclusion:

• It is impossible.

Ok, I like the way you put it, well structured. But:
- what do you mean with "2.b is same as 1.2"? maybe you meant 1.b instead of 1.2?
- at 2.a, I never said that this doesn't involve tinkering of the other skin (actually, of both), as it doesn't matter in evaluating if something is possible or not; remember, no pain, no gain - not everything can be done with a click of a mouse; this is also the reason why I said it's probably not worth the effort
- if your 4th bullet of the 1st list is the same as the 2nd bullet of the same list, like I suspected above, then that basically leaves only 1.b as your ... "mission impossible"
- apart from the fact that probabilities are, well, just probabilities in the lack of a definitive answer from the OP, I'd rather focus on the scenarios you claimed that it's impossible to find a solution for

So, that leads us to the infamous case 1.b where you say that "there is no way you can know if they are overlapping". I disagree with this assessment in the case of Rainmeter skins, because:
- each skin is basically a rectangle with the X, Y, W, H parameters/coordinates (I don't care about opaque or transparent pixels, since the question was formulated in a skin vs skin paradigm, without any reference to the type of pixels)
- each skin always knows its X, Y, W, H parameters/coordinates (nested syntax could help here to "force" such dynamic variables to be "seen" in non-dynamic sections of a skin), and these values can be passed to any other skin via [!SetVariable SomeVariable SomeValue SomeSkin]
- because of the above, the problem is basically reduced to finding out if two rectangles (that we know the coordinates of) intersect each other, and taking action based on that, which I'm sure you realize that it's entirely possible

Maybe I missed some meaning of something that you said, but it looks to me we're back to "mission possible" again - correct me if I'm wrong...

[death.crafter]

Ok, I like the way you put it, well structured. But:
- what do you mean with "2.b is same as 1.2"? maybe you meant 1.b instead of 1.2?
- at 2.a, I never said that this doesn't involve tinkering of the other skin (actually, of both), as it doesn't matter in evaluating if something is possible or not; remember, no pain, no gain - not everything can be done with a click of a mouse; this is also the reason why I said it's probably not worth the effort
- if your 4th bullet of the 1st list is the same as the 2nd bullet of the same list, like I suspected above, then that basically leaves only 1.b as your ... "mission impossible"
- apart from the fact that probabilities are, well, just probabilities in the lack of a definitive answer from the OP, I'd rather focus on the scenarios you claimed that it's impossible to find a solution for

So, that leads us to the infamous case 1.b where you say that "there is no way you can know if they are overlapping". I disagree with this assessment in the case of Rainmeter skins, because:
- each skin is basically a rectangle with the X, Y, W, H parameters/coordinates (I don't care about opaque or transparent pixels, since the question was formulated in a skin vs skin paradigm, without any reference to the type of pixels)
- each skin always knows its X, Y, W, H parameters/coordinates (nested syntax could help here to "force" such dynamic variables to be "seen" in non-dynamic sections of a skin), and these values can be passed to any other skin via [!SetVariable SomeVariable SomeValue SomeSkin]
- because of the above, the problem is basically reduced to finding out if two rectangles (that we know the coordinates of) intersect each other, and taking action based on that, which I'm sure you realize that it's entirely possible

Maybe I missed some meaning of something that you said, but it looks to me we're back to "mission possible" again - correct me if I'm wrong...

What the OP wants:

When he moves a skin, he doesn't want other skins to be overlapped.

So let's say you are right and it about two specific skins.

So what the OP wants can be summarised as, when he moves the first skin, it must not overlap the other skin.

How to achieve that:
1. Move so that it doesn't overlap the other skin.
2. Move it to place, then move the other skin so that they don't overlap anymore.

Then the question arises:
1. How would you know where the second config is?

That's where it becomes impossible.

Unless someone comes up with a ConfigXY plugin.

(not a bad idea, I may look in to it)

[Yincognito]

Then the question arises:
1. How would you know where the second config is?

That's where it becomes impossible.

Unless someone comes up with a ConfigXY plugin.

(not a bad idea, I may look in to it)

How do I know where the parent skin is in my custom tooltip skin approach, so I can position the latter next to the former, and even follow it as I drag the former around the screen (check the preview GIF)? Same principle here.
No need for a plugin, cause it's already there, and I said it earlier as well (well, not in terms of specifics, but anyway)...in schematics:

- in the 2nd config paste something along these lines:

Code: Select all

[SomeMeasure2]
...
OnUpdateAction=[!SetVariable Config2X [#CURRENTCONFIGX] "Config1"][!SetVariable Config2Y [#CURRENTCONFIGY] "Config1"][!SetVariable Config2W [#CURRENTCONFIGWIDTH] "Config1"][!SetVariable Config2H [#CURRENTCONFIGHEIGHT] "Config1"][!UpdateMeasure SomeMeasure1 "Config1"]
DynamicVariables=1

- then in the 1st config paste something along these lines:

Code: Select all

[SomeMeasure1]
...
OnUpdateAction=...do something, e.g. restrict movement, move back, check if the skin's rectangles intersect, based on the Config2X/Y/W/H variables communicated earlier by the 2nd config and this config's [#CURRENTCONFIGX/Y/W/H] ...
DynamicVariables=1

Sure, it needs tinkering in both skins, it won't be realtime, and it's not exactly for newbies, but again, it CAN be done. Plus, if you want to know any config's X or Y, you can always try to (web)parse(r) and interpret the related data in Rainmeter.ini, assuming the skin's SavePosition is set to 1. You can't get the W and H of skins from Rainmeter.ini, but you get some data on the X and Y. I'm not sure how often that data is updated though, so the safest bet is the skin communication approach mentioned earlier.

Anyway, if you want to make a plugin for this, go ahead, as it would probably simplify the above procedure. As for the speed, the above is just memory transfer, no disk writing involved, so, bar the update rate of the skins, it's more or less instantaneous.

So, mission possible again?

P.S. Didn't try this yet, but it might be possible to "transmit" the same, say, current config's X variable to every other active config, using something like [!SetVariable Config2X [#CURRENTCONFIGX] *]. If possible (should be, as it's possible for other bangs as well), that would solve (a part of) the multiple skin scenarios.

EDIT: And here's the proof (not for me, as I knew it would work as I use stuff based on this kind of ideas for years without issues, but for the "unbelievers", LOL) - just watch the Log:

Configs_1.0.0.rmskin

I commented out the [!UpdateMeasure SomeMeasure1 "#ROOTCONFIG#\Config1"] in Config2 to only trigger the [!Log ...] in Config1 once a second, but normally it should be left uncommented and set an UpdateDivider=-1 on Config1's [SomeMeasure1] so that the [!Log ...] or whatever other actions happen in Config1 as a result are only triggered by the measure in Config2. Was too lazy to repack stuff again, but I'm sure you'll get the idea.