[Feature] Inline RegExp substitution?

[JelleDekkers]

So uh, this would be pretty cool.

Let's say I have a few meter styles with loads of meters that use it. Here's an example:

Code: Select all

[MeterStyleDayNIconColorful]
[MeterStyleDayNIconMono]
[MeterStyleDayNWeekdayShort]
[MeterStyleDayNTemp]

The meters themselves are named "Day0WeekdayShort", "Day0Temp", etc. So if I wanted to refer to Day0Temp in Day0IconColorful in the meter style
using #CurrentSection# instead of having to set the X/Y value for every meter, it would be impossible since I can't remove part of the text called by that variable.

That's where this feature would come in handy. I suppose it would work something like this:

Code: Select all

RegExp("#CurrentSection#", "(.*)IconColorful", "\1Temp")

This would also really help with making numbered meters since you could grab just the number from the meter name and do calculations with that.

[Yincognito]

So uh, this would be pretty cool.

Let's say I have a few meter styles with loads of meters that use it. Here's an example:

Code: Select all

[MeterStyleDayNIconColorful]
[MeterStyleDayNIconMono]
[MeterStyleDayNWeekdayShort]
[MeterStyleDayNTemp]

The meters themselves are named "Day0WeekdayShort", "Day0Temp", etc. So if I wanted to refer to Day0Temp in Day0IconColorful in the meter style
using #CurrentSection# instead of having to set the X/Y value for every meter, it would be impossible since I can't remove part of the text called by that variable.

That's where this feature would come in handy. I suppose it would work something like this:

Code: Select all

RegExp("#CurrentSection#", "(.*)IconColorful", "\1Temp")

This would also really help with making numbered meters since you could grab just the number from the meter name and do calculations with that.

Yeah, something related / similar in effect has been proposed before, by me, ActiveColors and probably others as well in the past (disregard my slightly harsh words there, for which I apologized, but sometimes one has to take that risk in order for his suggestions to be at least taken into consideration more seriously). The good thing is that the devs know about it and "may discuss this internally" (as per Brian) at some point in the future.

That being said, the form in which this can be implemented is somewhat tricky, as sometimes one needs the "index" (i.e. the number from #CURRENTSECTION#), sometimes he needs the "root" part (i.e. the first word or words before a delimiter of some sort), sometimes he needs the "suffix" part (i.e. the last word or words in the variable). Also, the implementation would preferably have to be the "easiest" possible in terms of the code required to "upgrade" Rainmeter to it, so that the devs will have as few issues with potential bugs / backwards compatibility / etc. as possible.

In the meantime, if your only problem is the X and Y of a style in relation to a related style, you might want to explore putting all the style related meters inside containers, as the content of the container will move along with the container itself, whether we talk about absolute or relative positioning of the content inside the container. Personally I'm actually in the process of doing just that as I try to "merge" a number of separate skins into one to see if it reduces the CPU usage, without having to modify the X/Y of each style. If I set a container for each group of meters that was previously a separate skin, no coordinate modification is required on the X/Y of the styles, as the coordinates will be relative to those of the container, so moving the container itself will move the entire group. And yes, the fact that containers can't be nested (in case you have such a scenario) can be workarounded by separating the "nesting" (outside) container from the "nested" (inside) one and setting the X/Y of the "nested" one using relative positioning (which will reference the "first meter that is not content" as per the manual, aka the "nesting" / outside container).

In other words, if you create a container for each day, you can have identical styles being used for similar elements of whatever day (e.g. icon, weekday, temp, etc) without having to refer to a specific meter by name, since the elements will refer to the day container (whatever day it might be) in terms of positioning anyway.