Meters Auto-Adjust to container's height (?)

[RicardoTM]

You know best what you have in your skin. When it comes to the function I wrote, that can be customized differently, e.g get the the last 2 or 3 chars from the section name, etc. It's meant to help others, not to have its code set in stone, you know...

I just didn't quite understand the formula part, but I have to play more with it and read more on the thread you linked. For now I don't think changing where the index value is located at would solve the problem anyway.

[Yincognito]

I just didn't quite understand the formula part, but I have to play more with it and read more on the thread you linked.

If you mean the formula part in the .lua script, i.e. string.gsub(formula, '<x>', tostring(indexes[tonumber(occurrence)] or '0')), it just replaces <x> with the value of the indicated index in case you want to do math with that index directly when you call the function. It probably isn't absolutely needed, but it was mentioned in that thread and I thought it was a nice "feature" to have (though a bit useless since Rainmeter can do math too with the function result afterwards anyway).

[RicardoTM]

If you mean the formula part in the .lua script, i.e. string.gsub(formula, '<x>', tostring(indexes[tonumber(occurrence)] or '0')), it just replaces <x> with the value of the indicated index in case you want to do math with that index directly when you call the function. It probably isn't absolutely needed, but it was mentioned in that thread and I thought it was a nice "feature" to have (though a bit useless since Rainmeter can do math too with the function result afterwards anyway).

Oh, so that means the formula could be included directly instead of letting rainmeter do de math, so something like (<x>-1). Yah, it could be useful, not much in this case tho lol. But it gave me an idea, sadly I already implemented the groups I mentioned on my earlier post.

I was thinking I could use a different formula for the Y position on the shape meters. That have the s,

They go like sensor1 and sensor1s, which would be index 1 and 2, so I could simple add + 1 to the formula so it counts it as index 2.

No I think it would have to be something different.

Since sensor6 and sensor6s would be indices 11 and 12, so the formula should go times 2 minus 1 instead of only plus 1.

I gotta think about it.

EDIT.

Alright I tested and it works perfectly. I didn't understand the occurrence part at first. I thought first meant like the index was the first character and last the last. But it is the first occurrence of a number, so no matter where the number is, it will return it. So if you have more than one number on a section you can choose which number an so on. That's pretty neat.

So I only needed to do it like this: y=(Round([FGap]*([&S:sectionIndex('[#CurrentSection]','first','((<x>*2)-1)')]))-Round([FGap]*(([&S:sectionIndex('[#CurrentSection]','first','((<x>*2)-1)')])-1)))R
for the String meters (Sensor1,Sensor2 and so on).

and like this: y=(Round([FGap]*([&S:sectionIndex('[#CurrentSection]','first','(<x>*2)')]))-Round([FGap]*(([&S:sectionIndex('[#CurrentSection]','first','(<x>*2)')])-1)))R
for the shape meters (Sensor1s,Sensor2s and so on).

I guess I could also add the whole thing to the formula part like ([&FGap]*(<x>*2)).

Pretty neat function you made

[Yincognito]

No I think it would have to be something different.

Since sensor6 and sensor6s would be indices 11 and 12, so the formula should go times 2 minus 1 instead of only plus 1.

Something like this?

Code: Select all

function SectionIndex(section, occurrence, formula)
  local indexes = {}
  for index in section:gmatch('%d+') do table.insert(indexes, index) end
  if occurrence == 'first' then occurrence = 1 elseif occurrence == 'last' then occurrence = #indexes end
  return tostring(SKIN:ParseFormula(string.gsub(formula, '<x>', tostring(indexes[tonumber(occurrence)] or '0')))) or '0'
end

function SectionSuffix(section)
  -- short operational version (less clear):
  ------------------------------------------
  local m, s = section:match('%d+s?$') and 2 or 1, section:match('%d+$') and 1 or 0; return tostring(SectionIndex(section, 'last', '<x>') * m - s)

  -- long conditional version (more clear):
  -----------------------------------------
  -- if section:match('%d+s$') then return tostring(SectionIndex(section, 'last', '<x>') * 2 - 0)
  -- elseif section:match('%d+$') then return tostring(SectionIndex(section, 'last', '<x>') * 2 - 1)
  -- else return tostring(SectionIndex(section, 'last', '<x>') * 1 - 0)
  -- end
end

Code: Select all

[Variables]

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

---Measures---

[Script]
Measure=Script
ScriptFile=#@#Script.lua
UpdateDivider=-1

---Meters---

[Result7Text6]
Meter=String
Y=0r
FontColor=255,255,255,255
FontFace=Consolas
FontSize=16
Padding=5,5,5,5
AntiAlias=1
Text=Section Index 6  = [&Script:SectionSuffix('[#CURRENTSECTION]')]
UpdateDivider=-1
DynamicVariables=1

[Result7Text6s]
Meter=String
Y=0R
FontColor=255,255,255,255
FontFace=Consolas
FontSize=16
Padding=5,5,5,5
AntiAlias=1
Text=Section Index 6s = [&Script:SectionSuffix('[#CURRENTSECTION]')]
UpdateDivider=-1
DynamicVariables=1

[Result7Text6n]
Meter=String
Y=0R
FontColor=255,255,255,255
FontFace=Consolas
FontSize=16
Padding=5,5,5,5
AntiAlias=1
Text=Section Index 6n = [&Script:SectionSuffix('[#CURRENTSECTION]')]
UpdateDivider=-1
DynamicVariables=1

Section Suffix.jpg

The "X and Y or Z" parts are equivalent to "X ? Y : Z" in Rainmeter, in other words they're Lua's version of ternary operators aka conditionals.

EDIT: Just saw your edit. Well, guess I wrote another neat function, lol (in case you wanted to avoid different syntax in the Y for the <x>$ and <x>s$ sections). In order to use a common style, that is.

[RicardoTM]

Something like this?

Section Suffix.jpg
The "X and Y or Z" parts are equivalent to "X ? Y : Z" in Rainmeter, in other words they're Lua's version of ternary operators aka conditionals.

EDIT: Just saw your edit. Well, guess I wrote another neat function, lol (in case you wanted to avoid different syntax in the Y for the <x>$ and <x>s$ sections). In order to use a common style, that is.

Yup, that's pretty neat as well but pretty especific tho, I think "suffix" could be added (so it would be SectionSuffix(section,suffix)) so one could choose what suffix to take into account.

That way it could be used on any special case, like if someone had Sensor6 Sensor6s and Sensor6n and needed to count Sensor6n as well the result should be 11, 12, and 13. That would need the last *m-s formula to change to *m+s though.

By the way, yah, I used the "X and Y or Z" a lot on my raincolors.lua script (actually I think I only needed "or").

Edit. Just to add an example, on one of the Tutorial pages I have re made the gauge icons so they use the colorable icons I used on HSLiders.

To construct a complete gauge it requires 3 image meter + 2 string meters + 1 shape meter , So I have them as G1, G1B. G1G, G1F,, G1V and G1T. (Background, Gradient, Foreground, Value and Title).

Luckily on this precise construct they don't need to be part of anything since their position is relative to G1 anyway, so all other meters don't need to be counted as indices.

[Yincognito]

Yup, that's pretty neat as well but pretty especific tho, I think "suffix" could be added (so it would be SectionSuffix(section,suffix)) so one could choose what suffix to take into account.

That way it could be used on any special case, like if someone had Sensor6 Sensor6s and Sensor6n and needed to count Sensor6n as well the result should be 11, 12, and 13. That would need the last *m-s formula to change to *m+s though.

By the way, yah, I used the "X and Y or Z" a lot on my raincolors.lua script (actually I think I only needed "or").

Well, your example was specific too, so I wrote it based on that - up to you to improve or add to it if needed. Also, it's unclear what index order would s and n need to have in general, I suppose it won't be alphabetical or based on their char code, but rather user / skin specific, thus open to interpretation.

In the end, it was just an example on how to do it without affecting the original function and allowing usage in a common style via the same syntax, the rest is in fact quite specific from case to case (your Gauges might need one interpretation, another skin or suite might need another). Bar the greater flexibility that the formula offers at the cost of different syntax (not that much of a drawback to have 2 styles instead of just 1, just saying), the obvious alternative is to use plain indices without trying to index letters (or even using s6 instead of 6s if / when possible), but of course it's too late for that now in your case.

Yeah, I suspected you knew about the X and Y or Z, that part was just in the unlikely case you didn't yet (and potentially for whatever future readers, to explain a bit how the code works).

[RicardoTM]

Well, your example was specific too, so I wrote it based on that - up to you to improve or add to it if needed. Also, it's unclear what index order would s and n need to have in general, I suppose it won't be alphabetical or based on their char code, but rather user / skin specific, thus open to interpretation.

In the end, it was just an example on how to do it without affecting the original function and allowing usage in a common style via the same syntax, the rest is in fact quite specific from case to case (your Gauges might need one interpretation, another skin or suite might need another). Bar the greater flexibility that the formula offers at the cost of different syntax (not that much of a drawback to have 2 styles instead of just 1, just saying), the obvious alternative is to use plain indices without trying to index letters (or even using s6 instead of 6s if / when possible), but of course it's too late for that now in your case.

Yeah, I suspected you knew about the X and Y or Z, that part was just in the unlikely case you didn't yet (and potentially for whatever future readers, to explain a bit how the code works).

I just mention it because it could be a nice and more general neat function, but honestly the sectionIndex function is already general and pretty good since it supports the formulas already, so the other function (in my case) is not necessary. The original function can be applied to specific cases anyway. In my case I already had different styles for both kind of meters since the normal ones are strings and the s ones are shapes.

Name them as SensorS1 was not possible (well not impossible either lol), but Sensor1s worked better to use "[#CurrentSection]s" but yeah it's too late for that, since that naming comes from 1.0 version lol

Just to add something educational for future readers as well, here's what "x or y and z" aka logical operators are: https://www.lua.org/manual/5.1/manual.html#2.5.3

[Yincognito]

I just mention it because it could be a nice and more general neat function

I'm all for being as general as possible without sacrificing flexibility, so if you have suggestions, I'm all ears (or eyes).

That being said, it's difficult to cover all potential specific cases related to how non numbers would be indexed. As much as I like "one size fits all" solutions via complete flexibility, there are cases that do depend on skin implementation and where skin designers would have different expectations on what the function output should eventually be, and my 'occurrence' and 'formula' parameters were added precisely for that reason.

As you just said, they already offer reasonable freedom in choosing how the output looks like, and I'm afraid that more adjustments on that front would make the function a bit too specific to serve as a general one that anyone can use as desired.

[RicardoTM]

I'm all for being as general as possible without sacrificing flexibility, so if you have suggestions, I'm all ears (or eyes).

I did some testing on sectionSuffix by removing the s and adding ..suffix.. but it was still not that "general" due to the formula, I couldn't come up with a better way to put it. Testing with 6 meters with different suffixes all with the same index. The thing is that each of them requires a different formula, and as you mentioned, it would only work in a specific order. The original sectionIndex function solves this although it requires meter styles with different formulas for each suffix. This is not that unfortunate given that one normally would create different suffixes because each of them is a different kind of meter, so a different style would be needed anyway.

So short answer is noup, I don't really have suggestions. I think sectionIndex is good as it is, and sectionSuffix could be improved but still don't know how, nor why given that sectionIndex works great for any scenario already.

That being said, it's difficult to cover all potential specific cases related to how non numbers would be indexed. As much as I like "one size fits all" solutions via complete flexibility, there are cases that do depend on skin implementation and where skin designers would have different expectations on what the function output should eventually be, and my 'occurrence' and 'formula' parameters were added precisely for that reason.

As you just said, they already offer reasonable freedom in choosing how the output looks like, and I'm afraid that more adjustments on that front would make the function a bit too specific to serve as a general one that anyone can use as desired.

Yup, sectionIndex must stay as it is, it doesn't need any improvement. I only changed its name to sIx to shorten it a little.

Maybe add so if you leave the parameters empty it would always take 'first' and '<x>' as default parameters, so one could shorten it a little bit more would be nice, so if I put [&S:sIx('[#CurrentSection]')] it would simply give me the index without the need to write the whole [&S:sIx('[#CurrentSection]','first','<x>')]. This for general use cases that don't need a formula of course.

[Yincognito]

I did some testing on sectionSuffix by removing the s and adding ..suffix.. but it was still not that "general" due to the formula, I couldn't come up with a better way to put it. Testing with 6 meters with different suffixes all with the same index. The thing is that each of them requires a different formula, and as you mentioned, it would only work in a specific order. The original sectionIndex function solves this although it requires meter styles with different formulas for each suffix. This is not that unfortunate given that one normally would create different suffixes because each of them is a different kind of meter, so a different style would be needed anyway.

So short answer is noup, I don't really have suggestions. I think sectionIndex is good as it is, and sectionSuffix could be improved but still don't know how, nor why given that sectionIndex works great for any scenario already.



Yup, sectionIndex must stay as it is, it doesn't need any improvement. I only changed its name to sIx to shorten it a little.

Maybe add so if you leave the parameters empty it would always take 'first' and '<x>' as default parameters, so one could shorten it a little bit more would be nice, so if I put [&S:sIx('[#CurrentSection]')] it would simply give me the index without the need to write the whole [&S:sIx('[#CurrentSection]','first','<x>')]. This for general use cases that don't need a formula of course.

Actually, for my personal needs, I use fewer chars for the script measure and the function, so we think alike in that regard. I only used the full names for public clarity for anyone reading it, that's all.

Having a variable number of arguments via SectionIndex(...) in Lua is a good idea, I use it too in some of the other scripts I wrote. The only potential difference is that while '[#CURRENTSECTION]' and '<x>' would be obvious candidates as defaults if no arguments are given, I would incline for 'last' as the default, since folks tend to write the specific index of a section last anyway, e.g. Folder3File5 or String7Index4 (by the way, 'last' is the last occurrence of an index, not the last chars of a section name, so you can have other non numeric chars after the last index regardless, as you already know).

I'll think about posting such a version somewhere in the following days. Might be here or even in the Tips & Tricks section of the forum, but I'll link to it if necessary. Thanks for the suggestions (if impatient, you can implement them yourself in the meantime, of course, it's a public function anyway)!