It is currently March 29th, 2020, 12:31 am

[BUG]CURRENTCONFIGX/Y Issue

Report bugs with the Rainmeter application and suggest features.
User avatar
Yincognito
Posts: 1070
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

[BUG]CURRENTCONFIGX/Y Issue

Post by Yincognito »

Here I am again, with another [BUG] episode for Rainmeter's developers (sorry 'bout that, folks)... :D

Test skin:

Code: Select all

[Variables]

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[MeasureTest]
Measure=Calc
UpdateDivider=-1
;OnUpdateAction=[!WriteKeyValue "#CURRENTCONFIG#" AnchorX "" "#SETTINGSPATH#Rainmeter.ini"][!WriteKeyValue "#CURRENTCONFIG#" AnchorY "" "#SETTINGSPATH#Rainmeter.ini"][!WriteKeyValue "#CURRENTCONFIG#" WindowX (#WORKAREAX#+#WORKAREAWIDTH#/2-#CURRENTCONFIGWIDTH#/2) "#SETTINGSPATH#Rainmeter.ini"][!WriteKeyValue "#CURRENTCONFIG#" WindowY (#WORKAREAY#+#WORKAREAHEIGHT#/2-#CURRENTCONFIGHEIGHT#/2) "#SETTINGSPATH#Rainmeter.ini"][!UpdateMeter *][!Redraw]
;OnUpdateAction=[!WriteKeyValue "#CURRENTCONFIG#" AnchorX "50%" "#SETTINGSPATH#Rainmeter.ini"][!WriteKeyValue "#CURRENTCONFIG#" AnchorY "50%" "#SETTINGSPATH#Rainmeter.ini"][!WriteKeyValue "#CURRENTCONFIG#" WindowX "50%" "#SETTINGSPATH#Rainmeter.ini"][!WriteKeyValue "#CURRENTCONFIG#" WindowY "50%" "#SETTINGSPATH#Rainmeter.ini"][!UpdateMeter *][!Redraw]
DynamicVariables=1

---Meters---

[MeterTest]
Meter=STRING
X=0
Y=0
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
UpdateDivider=-1
Text="Skin's X,Y = #CURRENTCONFIGX#, #CURRENTCONFIGY#"
DynamicVariables=1
Scenario steps:
1) according to the manual, "setting WindowX, WindowY, AnchorX and AnchorY all to 50% the config will be truly centered in the primary monitor regardless of screen resolution or aspect ratio". Do just that for the above skin, by editing your Rainmeter.ini, or uncomment the corresponding OnUpdateAction above to let the skin do it for you
2) now, with the skin above unloaded, try to load it
3) after checking the result, refresh the skin and check the result again

The issue:

On loading the above centered skin, the #CURRENTCONFIGX# and #CURRENTCONFIGY# displayed are actually the AnchorX and AnchorY, and not the WindowX and WindowY, as it should be the case. On subsequent skin refresh(ing), the displayed #CURRENTCONFIGX# and #CURRENTCONFIGY# become the correct ones, e.g. CURRENTCONFIGX = WindowX = AnchorX - (SkinWidth / 2) and such (compared to the incorrect CURRENTCONFIGX = AnchorX = ((WorkAreaWidth - WorkAreaX) / 2) at skin load). <= replaced this with the right explanation below, see the EDIT here.

On loading the above centered skin, the #CURRENTCONFIGX# and #CURRENTCONFIGY# displayed are actually the WindowX and WindowY, and not the WindowX-AnchorX and WindowY-AnchorY, as it should be the case. On subsequent skin refresh(ing), the displayed #CURRENTCONFIGX# and #CURRENTCONFIGY# become the correct ones, e.g. CURRENTCONFIGX = WindowX - AnchorX = (#SCREENAREAWIDTH# - #SCREENAREAX#) / 2 - #CURRENTCONFIGWIDTH# / 2 and such (compared to the incorrect CURRENTCONFIGX = WindowX = (#SCREENAREAWIDTH# - #SCREENAREAX#) / 2 at skin load).

Even easier to follow: my monitor is 1366 x 768. For a skin having those 4 values above (WindowX/Y and AnchorX/Y) set to 50% in Rainmeter.ini:
- the #CURRENTCONFIGX# and #CURRENTCONFIGY# reported on load are (incorrectly) 683 and 384, respectively (i.e. screen center coordinates)
- on skin refresh, the two variables above (correctly) subtract half of the skin's width and height from 683 and 384, displaying the accurate coordinates

The question:
Why does this happen and how to correct it, if possible? And if not possible, is this a bug or something else?
Also, would the (hypothetical) bug be solved before I publish my new skin suite version (where I have a centered skin that doesn't correctly display the custom tooltips because of the above)? Not in a hurry by any means - just asking... ;-)
Last edited by Yincognito on March 22nd, 2020, 10:04 pm, edited 3 times in total.
User avatar
SilverAzide
Posts: 713
Joined: March 23rd, 2015, 5:26 pm

Re: [BUG or NOT]CURRENTCONFIGX/Y Issue

Post by SilverAzide »

Could the problem be that you are using DynamicWindowSize=1? :confused:
What happens if you set the skin to a fixed size instead?
DeviantArt Gadgets More...
User avatar
Yincognito
Posts: 1070
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG or NOT]CURRENTCONFIGX/Y Issue

Post by Yincognito »

SilverAzide wrote:
March 21st, 2020, 11:35 pm
Could the problem be that you are using DynamicWindowSize=1? :confused:
What happens if you set the skin to a fixed size instead?
Pretty much the same thing, unfortunately. Thanks for the idea, I thought that it might have something to do with the dynamic window size, but it doesn't. I can, in a way, understand this, since aligning strings to "center" suffers from some similar "issues" where you have to take the alignment into account, but then again, #CURRENTCONFIGX# and #CURRENTCONFIGY# should be the "real", absolute pixel coordinates of a skin, otherwise what would be the point of them (we would go back to compute everything using long [Meter:X/Y/W/H] formulas)...
User avatar
Yincognito
Posts: 1070
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG]CURRENTCONFIGX/Y Issue

Post by Yincognito »

Ok, so it appears this bug isn't going to be fixed (don't ask me why though). My advice is to avoid setting a skin position by percentage by any means, as it would lead to nasty visual glitches (in the case of animations) or wrong positioning of related elements (in the regular usage cases) when one needs to use the built in #CURRENTCONFIGX# and #CURRENTCONFIGY# variables of that skin. Basically, in such a case, #CURRENTCONFIGX# and #CURRENTCONFIGY# are not reliable.
User avatar
jsmorley
Developer
Posts: 20425
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [BUG]CURRENTCONFIGX/Y Issue

Post by jsmorley »

In my personal view, manually setting AnchorX/AnchorY/WindowX/WindowY are only of any use in a Layout, where you want to have some "starting" position for the skin(s) when the Layout is loaded. Since WindowX and WindowY are always going to dynamically change, even as a percentage, when you in any way move the skin on the screen, I don't see that as a good way to ensure that a skin is "centered", or placed in any other static position relative to the screen on an ongoing basis.

I don't at all follow what the issue is that you are having, as I have yet to see any example that demonstrates it in any way I can follow.

When brian comes around and takes a look at this, he might have a better idea of what is going on and what can and can't be done about it.
User avatar
Yincognito
Posts: 1070
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG]CURRENTCONFIGX/Y Issue

Post by Yincognito »

jsmorley wrote:
March 22nd, 2020, 2:54 pm
In my personal view, manually setting AnchorX/AnchorY/WindowX/WindowY are only of any use in a Layout, where you want to have some "starting" position for the skin(s) when the Layout is loaded. Since WindowX and WindowY are always going to dynamically change, even as a percentage, when you in any way move the skin on the screen, I don't see that as a good way to ensure that a skin is "centered", or placed in any other static position relative to the screen on an ongoing basis.
That's exactly the case: I use a layout to set that, in order to always center the skin on any monitor on load.
jsmorley wrote:
March 22nd, 2020, 2:54 pm
I guess I don't understand how you can think that Rainmeter can know the width and height of a skin before it has loaded it and drawn it for the first time.
Yes, that's a very good point - and probably the reason why this happens only on load and not on subsequent skin refresh. The thing is, in the particular case that caused this thread (i.e. my case), the skin was already loaded and drawn, and the #CURRENTCONFIGX# and #CURRENTCONFIGY# were still having the wrong values - just because it happened on skin load.
jsmorley wrote:
March 22nd, 2020, 2:54 pm
I don't at all follow what the issue is that you are having, as I have yet to see any example that demonstrates it in any way I can follow.
I can provide at least two examples: mine (regular usage case) and another one from the thread I linked to (animation case). Mine is obviously more complicated, as it would take an eternity to simplify the skin and post it here, and the other one is much simpler. I can post both, if you want - just let me know if I should do this, as I don't like to do something without some sort of "result" (even if it's something like "we can't do this because..." type of result).
User avatar
jsmorley
Developer
Posts: 20425
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [BUG]CURRENTCONFIGX/Y Issue

Post by jsmorley »

Well, it seems to me that #CURRENTCONFIGX/Y/W/H# have no possible way to be reliable until the end of the first update cycle, after the skin has been loaded, updated and "drawn" the first time. Since OnRefreshAction can't use "dynamic" values, they really won't do you any good there either. I think that to use what is derived from the WindowX/WindowY values in Rainmeter.ini, and use them in conjunction with the "current" skin width and height, you simply must use that in a Calc or other measure that will be executed on at least the "second" update cycle of the skin.

I mean in some sense, those #CURRENTCONFIGX/Y/W/H# mean "what it WAS at the end of the last redraw", not really "what it IS", and certainly not "what it WILL BE". When a skin is first loaded, there is no "last redraw".
User avatar
Yincognito
Posts: 1070
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG]CURRENTCONFIGX/Y Issue

Post by Yincognito »

jsmorley wrote:
March 22nd, 2020, 3:18 pm
Well, it seems to me that #CURRENTCONFIGX/Y/W/H# have no possible way to be reliable until the end of the first update cycle, after the skin has been loaded, updated and "drawn" the first time.
More like until the refresh happens. Again, Jeff, I'm getting the wrong values for #CURRENTCONFIGX/Y# even after the skin has been loaded, updated and drawn the first time. Only a (manual, possibly automatic although I didn't try the latter?) refresh "solves" the issue... but only for it to happen again on skin unload + skin load.
jsmorley wrote:
March 22nd, 2020, 3:18 pm
I mean in some sense, those #CURRENTCONFIGX/Y/W/H# mean "what it WAS", not really "what is IS", and certainly not "what it WILL BE".
Well, then it's not #CURRENTCONFIGX/Y/W/H#, but #LASTCONFIGX/Y/W/H# ... and that barely has any relevance to a skin designer, really. I can understand that it's not "what it WILL BE", but what I'm trying to say is that in this particular case, it's not even "what it WAS" / "what is IS", as mentioned above. It's like the 50% of WindowX and WindowY are not converted to actual values even after the skin is drawn, only after the skin is refreshed.
jsmorley wrote:
March 22nd, 2020, 3:18 pm
When a skin is first loaded, there is no "last redraw".
Now it's me having trouble following you on this... :???:
User avatar
Yincognito
Posts: 1070
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG]CURRENTCONFIGX/Y Issue

Post by Yincognito »

jsmorley wrote:
March 22nd, 2020, 2:54 pm
I don't at all follow what the issue is that you are having, as I have yet to see any example that demonstrates it in any way I can follow.
This is the simple animation example, as the visual glitches are more obvious:
GameLauncher_1.0.0.rmskin
The skin will automatically load when installed. Clicking on the blue globe (i.e. the first skin) will show a battery icon (i.e. a second skin) that will "zoom in", tint and alpha on hover. The battery is set to show in the center of the screen, of course. What happens is that, on hover:
- the battery will not "zoom in" in the center of the skin, but first it will move towards the right-bottom of the center, then zoom at those coordinates
- if you hover just a little bit to the right (or to the bottom) of the opaque pixels of the battery image, the battery will continuously flicker and switching "zoom out"/"zoom in" states for ever

Uncommenting the commented OnRefreshAction + LeftMouseUpAction coupled with commenting the uncommented similar options (hopefully you can follow me on this) in GameLauncher.ini will solve the issue, as the second/battery skin position will not be a percentual value.
You do not have the required permissions to view the files attached to this post.
User avatar
Yincognito
Posts: 1070
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG]CURRENTCONFIGX/Y Issue

Post by Yincognito »

Short workaround for the issue:

Code: Select all

[MeasureCounterFunction]
Measure=Calc
Formula=Counter
IfEqualValue=2
IfEqualAction=[!Refresh]
This automatically refreshes the skin on its 2nd update cycle (since refreshing on the 1st update cycle will prevent the default fade in of the skin when loading). It still feels wrong that this has to be done though, especially since there's no other way of knowing whether the skin is percentually centered (or just percentually positioned) other than parsing Rainmeter.ini using a WebParser measure. It happens that I know one of my skins is set up this way, but for a skin whose properties are unknown yet, having both a Calc measure and a WebParser measure just to correct this problem is ... well, strange, to put it this way.

Just for (my) reference - Skin.cpp at GitHub (search term: m_ScreenX)

EDIT: Apparently, I got it all wrong regarding the subtraction thing (edited the first post accordingly) - it's AnchorX/Y (relative to skin dimensions) that are subtracted from WindowX/Y (relative to screen dimensions) - but that doesn't change anything. A reevaluation of #CURRENTCONFIGX# and #CURRENTCONFIGY# (not sure if also of m_ScreenX and m_screenY from the Rainmeter's source code) should be done after the skin finishes its initialization / first update / refresh or its internal counter > 1, in order for these 2 built in variables to receive the correct values. After all, it's not for nothing that these 2 built in variables are dynamic - it's something that a skin refresh bang does and a skin "activation" doesn't that's preventing these variables to have the correct values after skin "activation" / loading (but have them after a skin refresh)...