It is currently May 25th, 2020, 2:18 pm

[Feature Suggestion] Current Section Index

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

[Feature Suggestion] Current Section Index

Post by Yincognito »

In Rainmeter, one can get the name of the section in which the variable is used with the help of the #CURRENTSECTION# built-in section variable. This is helpful, among other things, to copy paste the same (repetitive) code to different sections without bothering to change the section name on each use. How about a more specific built-in section variable called, say, #CURRENTSECTIONINDEX#, which would return the trailing number at the end of a current section name (or, if the Rainmeter developers are nice enough, return either the first or the last number in a current section name)?


For the trailing number implementation, it would make this:

Code: Select all

[MeasureCPUUsage13]
Measure=CPU
Processor=13
into this (#CURRENTSECTIONINDEX#=13):

Code: Select all

[MeasureCPUUsage13]
Measure=CPU
Processor=#CURRENTSECTIONINDEX#

For the first number implementation, it would make this:

Code: Select all

[Measure12CPU13Usage]
Measure=CPU
Processor=12
into this (#CURRENTSECTIONINDEX#=12):

Code: Select all

[Measure12CPU13Usage]
Measure=CPU
Processor=#CURRENTSECTIONINDEX#

For the last number implementation, it would make this:

Code: Select all

[Measure12CPU13Usage]
Measure=CPU
Processor=13
into this (#CURRENTSECTIONINDEX#=13):

Code: Select all

[Measure12CPU13Usage]
Measure=CPU
Processor=#CURRENTSECTIONINDEX#

Of course, which implementation would be chosen is up to the developers (if interested, that is). Personally, I would lean towards the 'last number' one, since it doesn't always make sense to place the number at the very end of the section name as it can be in the middle of it, and placing it towards the start of that name is rarely used.

P.S. Obviously, it would be great if the #CURRENTSECTIONINDEX# variable could be used as a numerical value as well, apart from using it as a string value, so that it would be suited for both an IfCondition and an IfMatch attached to the section, but I'm not sure this is possible - I'm just speculating...
User avatar
Active Colors
Moderator
Posts: 548
Joined: February 16th, 2012, 3:32 am

Re: [Feature Suggestion] Current Section Index

Post by Active Colors »

Yes please! Such thing will easy things up for repitative meters. In fact I asked before for something similar regarding repetitive things. Specifically for:
trailing value here
the whole meter name but trailing value here
User avatar
jsmorley
Developer
Posts: 20627
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [Feature Suggestion] Current Section Index

Post by jsmorley »

I'm sorry, but 99.99% of all authors and users would simply say "why in the world would I need that?"

Might be nice if you were cranking out 10 skins a day or something I guess. I'm just not a big fan of these ideas to automate or simplify writing a skin. It's really not that much repetitive work, and I'm perfectly fine with carefully and lovingly hand-crafting a skin. Automation is really the only way to make M&M's, not really the highest priority for making a Stradivarius.

I'm not saying it's a "bad" idea, not at all. I'm simply saying it's an "unimportant" idea. Just my personal opinion, I'm one voice of many.

One might also say that it is a hideous, pointless, Rube Goldberg of a solution in a vain search for a problem. You might very well think that, I couldn't possibly comment.
User avatar
Yincognito
Posts: 1610
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature Suggestion] Current Section Index

Post by Yincognito »

jsmorley wrote:
May 4th, 2020, 12:30 am
I'm sorry, but 99.99% of all authors and users would simply say "why in the world would I need that?"

Might be nice if you were cranking out 10 skins a day or something I guess. I'm just not a big fan of these ideas to automate or simplify writing a skin. It's really not that much repetitive work, and I'm perfectly fine with carefully and lovingly hand-crafting a skin. Automation is really the only way to make M&M's, not really the highest priority for making a Stradivarius.

I'm not saying it's a "bad" idea, not at all. I'm simply saying it's an "unimportant" idea. Just my personal opinion, I'm one voice of many.

One might also say that it is a hideous, pointless, Rube Goldberg of a solution in a vain search for a problem. You might very well think that, I couldn't possibly comment.
And how would you know what "99.99% of all authors and users" need, want or believe? The way I see it by browsing on the forum is that 99.99% of the more or less valid and useful suggestions by those "99.99% of all authors and users" get ignored or, in the best case scenario, finally get implemented after a year or so and constant pushing for the addition of that feature. The majority argument is never good to justify or to rate the quality or the usefullness of an idea, as 99.99% of the important things in this world (and in Rainmeter, in particular) come exactly from the 00.01% whose ideas you deem "unimportant" (see both the production and usage of Stradivarius, and there are literally thousands of similar examples - if folks always did what 99.99% of them thought, human race would still be in stone age to this day, for example).

Anyway, that's beside the point, as you'll either won't accept, understand or even care about these realities. I'll just say that I expected this answer (well, actually, I didn't expect any answer, if not for Active Colors reply, LOL), even though I gave my best shot to make it as trivial to implement (and accept) as possible. The suggestion is just as valid as #CURRENTSECTION# for the simple reason that they are (or would be) similar in usage and implementation. One idea gets done probably without even asking, the other is ignored and refused cause it comes from the so called 00.01% of the user base. If all developers would think like that, nothing would ever get done, as all suggestions initially come from a single individual (so the 99.99% argument of stagnation is always going to be easy to bring up into the conversation). Pfff...

The funny thing is that on another thread you said that, and I quote:
jsmorley wrote:
April 28th, 2020, 6:38 pm
I think tips and tricks for how you can simplify your code, make it more readable, use better naming conventions, whatever are GREAT.
but on this, it's the exact opposite:
jsmorley wrote:
May 4th, 2020, 12:30 am
I'm just not a big fan of these ideas to automate or simplify writing a skin.
What could be the cause of this sudden change of opinions, I wonder? Oh, yeah, I think I got it: on both the other thread and this one you rallied to the idea that required no change whatsoever to the current features of Rainmeter. It's not even about the "99.99% of all authors and users" that alledgedly share your opinion, backwards compatibility (100% in this case), impact on performance (0% in this case), a fundamental change in how Rainmeter works (not even a question here), it's simply a matter of having to add one or two lines of code to Rainmeter. I understand the limited time resources of the developers, and more or less agree with the idea that the repetitive work is not that hard (not that it's not that much such work, as you suggested though, which is false), but what I can't understand is why features that are so simple to get done (and so obviously beneficial) are rejected. I won't even ask about my other suggestion regarding merging layouts, since this one which is infinitely easier to add is dismissed.

I'll end up with a quote from Brian here:
Brian wrote:
April 23rd, 2020, 9:01 am
I don't think any of the developers are against some sort of "dynamically created objects" or "repeating section creation" per se, I just think we haven't seen any idea that an average user can follow easily.

-Brian
No kidding?! How about this one, LOL? It checks all the boxes, don't you think? Dead easy to understand for the regular user, no breaking of the INI format, no Rainmeter rewriting needed, no backwards compatibility issues, no impact on performance, no hard work implementing it, etc. - just a simple built-in variable, available in Rainmeter. The answer is of course: no, can't do. The "99.99%" of the folks who simply adore replicating slightly different sections in their skins (sarcasm gently inserted here) surely must disagree with this "hideous", "Rube Goldberg" idea, LMAO...

P.S. By the way, this doesn't automate things as you claimed. It only helps in avoiding having to modify a single variable or whatever, in each similar section you're copy pasting in the skins. You'd still have to modify it in the section's name, of course, but at least that's only a single modification required in every section.
User avatar
jsmorley
Developer
Posts: 20627
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [Feature Suggestion] Current Section Index

Post by jsmorley »

Well, I'm sorry you feel that way. We try really hard to support the community and make Rainmeter better.
User avatar
Yincognito
Posts: 1610
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature Suggestion] Current Section Index

Post by Yincognito »

jsmorley wrote:
May 4th, 2020, 12:56 pm
Well, I'm sorry you feel that way. We try really hard to support the community and make Rainmeter better.
I know you do, and personally, I try to come up with suggestions that are trivial to implement (yeah, I'm actually thinking about your limited resources). Me, I'm sorry that even these simple ideas have no effect. I'm probably wrong with this, but it's easy to understand why this might seem at times as obtuse thinking, rather than following a set of principles (which I fully agree with) regarding Rainmeter.
User avatar
Active Colors
Moderator
Posts: 548
Joined: February 16th, 2012, 3:32 am

Re: [Feature Suggestion] Current Section Index

Post by Active Colors »

To support what Yincognito said it is not for making a more lazy life copy-pasting-renaming things. It is just lot more logical to structure skins.
I would really like to get back to my #CURRENTROOTSECTION# idea because it exactly does not break anything existing in rainmeter and can be used for Yincognito's idea as well, I will describe below. #CURRENTROOTSECTION# obtains the meter name just like #CURRENTSECTION# does but omits everything after (in my idea) pipe sign. One more time, simple but realistic example.

For instance, I have a simple dock skin which has around 10 icons. It is not modular, it doesn't have extra super powers, no lua, no smartass scripts, no addons. Pure Rainmeter. The structure for each icon is like this:

- Root area for the elements
- Icon
- Tooltip image
- Tooltip text
- Tooltip text shadow
- plus possible extra stuff for context menu
- plus some other variables for specifying pathes for image, address to open, text for tooltips, etc...

I have this simple structure like this:

[Icon1] (main 'root' meter)
[Icon1_Image] (the rest elements)
[Icon1_Tooltip]
[Icon1_Text]
[Icon1_Textshadow]

If we had such ability to specify root it would be much simpler to relatively position every element to one main 'root' meter. And it is applicable not only for a dock. In any skin where you relatively position meters around one element this technique is practical. It is even more useful to get rid of repetitons, for instance if you take the same dock skin you will need to rewrite (re-copy-paste) one formula 10 times and then change number in meter names another 10 times (Icon1, Icon2, ...). The same process for other elements. This is not for automation or dynamicly creating meters. It is a simple structural logic. Then imagine another case when making such skin you realize you want to change the formula. In fact it is the same everywhere but now you have to transport it accross the skin another 10 times and rename meters another 10 times. Who had such case? I suppose many.

What we have now:

Code: Select all

[Icon1_Tooltip]
Y=([Icon1:Y]-20)

[Icon2_Tooltip]
Y=([Icon2:Y]-20)

[Icon3_Tooltip]
Y=([Icon3:Y]-20)

[Icon4_Tooltip]
Y=([Icon4:Y]-20)

[Icon5_Tooltip]
Y=([Icon5:Y]-20)

What we could have:

Code: Select all

[StyleTooltip]
Y=([#CURRENTROOTSECTION:Y]-20)

[Icon1|Tooltip]
MeterStyle=StyleTooltip

[Icon2|Tooltip]
MeterStyle=StyleTooltip

[Icon3|Tooltip]
MeterStyle=StyleTooltip

[Icon4|Tooltip]
MeterStyle=StyleTooltip

[Icon5|Tooltip]
MeterStyle=StyleTooltip

It is then also possible to use Yincognito's ideas. Since we separate section name into two parts, the left side as I said is ROOT, the right side becomes TRAIL.
In my example #CURRENTROOTSECTION# in [Icon1|Tooltip] refers to Icon1. Respectively, #CURRENTTRAILSECTION# in [Icon1|Tooltip] will refer to Tooltip.


Tell me how much it is illogical and hard to implement to grab the meter name just like the #CURRENTSECTION# does but instead to take a part of it divided by pipe character.

And of course, I value all the hard work and dedication of the Rainmeter team and even more being like a small family here especially since I have been here almost 10 years. This is just my request for making the skin construction process and look more logical based on my experience making skins for the past years.
User avatar
Brian
Developer
Posts: 1994
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: [Feature Suggestion] Current Section Index

Post by Brian »

I think in some ways we all need to simmer down a little here. With all that is going on in the world and the stresses of everyday life, I think we need to stop and think about others a little more and try to put ourselves in other's shoes.

I think this is perfect time to remind everyone that the Rainmeter developers are volunteers. We spend a small amount of our ever-decreasing free time on this project. You may have noticed that most of the team has either moved on to bigger and better things, or completely disappeared from the project. At this moment, there is jsmorley and me (with some help from poiru from time to time). jsmorley spends a significant amount of time here on the forums helping everyone he can get the most out of Rainmeter. Sure, sometimes he gets a little snarky now and then, like we all do - but, he has some incredible patience and cleverness that is just perfect for our community. He is the best of us.

For me, my time has been limited for the past year (maybe longer), and will continue for at least another month (hopefully, not much longer than that). I just don't have time to really think through a project, implement a solution, and tweak it to work seamlessly with the rest of the code. I haven't even had time to really review some code submitted via github. You should see my Rainmeter "todo" list.

Anyway, I am just trying to remind everyone that we are just regular people. Rainmeter is a passion and hobby...but it doesn't pay the bills. Like with any passion, we tend to work on our own inspiration, but "seeing" the inspriation of others is difficult. I can't tell you how many times we have argued discussed internally about some issue/feature - and I think the real conflict is one person "thinks" their ideas are a better fit for someone else's ideas. The key to making it all work is a cool head, respect for others, and compromise. We try our best.

From a user standpoint, I can certainly understand the "you don't listen to us" argument. We often don't respond to requests for a variety of reasons (which I won't get into)...but we do read them all and spend at least a little time thinking about them (most of the time). I have been thinking about this very topic since it was started...but like I said above, time has stopped me from even investigating the complexities of implementing this, let alone the merits of the idea. It is difficult to comment on something I have no idea if it can be done easily.





So.........back to the topic....
Yingcognito wrote: It checks all the boxes, don't you think? Dead easy to understand for the regular user, no breaking of the INI format, no Rainmeter rewriting needed, no backwards compatibility issues, no impact on performance, no hard work implementing it, etc. - just a simple built-in variable, available in Rainmeter.
This would have a smallish impact on performance. #CURRENTSECTION# is the black sheep of Rainmeter built-in variables. It requires special handling. We actually have several "workarounds" throughout the code to make it work properly. I also disagree with the "dead easy to understand" part....at least a little. The most basic user will grapple with what "index" means in this case...but, with proper documentation, this isn't really an issue.

On to the "usefullness" part. jsmorley is right, the vast majority of skin authors probably won't ever use this. That doesn't mean it isn't a good fit, or useful in some situations. It's just a comment that is more about "priority" than anything else. The more time we spend on this, the less time we spend on other projects (like proper DPI support).

I think the "trailing index" version of this is the better idea. We may discuss this internally. :D

-Brian

PS - Active Colors, let's keep this topic about #CURRENTSECTIONINDEX#. I understand this is a related topic, but it's easier to follow your idea in its own thread.
User avatar
Yincognito
Posts: 1610
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature Suggestion] Current Section Index

Post by Yincognito »

Active Colors wrote:
May 4th, 2020, 3:11 pm
It is then also possible to use Yincognito's ideas. Since we separate section name into two parts, the left side as I said is ROOT, the right side becomes TRAIL. In my example #CURRENTROOTSECTION# in [Icon1|Tooltip] refers to Icon1. Respectively, #CURRENTTRAILSECTION# in [Icon1|Tooltip] will refer to Tooltip.
You're right, our ideas are related, as they both look to separate #CURRENTSECTION# into logical parts that can be then used as variables in other circumstances, in order to simplify calculations based on their values. I am more interested in the "trailing" (well, not necessarily trailing, just the number) part and you're equally interested in the "leading" part. I'll play the devil's advocate for a moment and say that your (and my) particular scenario can be (sort of) solved using the current Rainmeter features, presented in the code below - but read the Drawback section, for the explanation of why this is just a "sort of" solution, and not an ideal one. This is where a #CURRENTROOTSECTION# / #CURRENTTRAILSECTION# / #CURRENTINDEX# implementation would come in handy.

Code:

Code: Select all

[Variables]
Index=1

[Rainmeter]
Update=1000
SkinWidth=275
SkinHeight=225
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

---Styles---

[StyleBase]
FontFace=Consolas
FontColor=255,255,255,255
FontSize=16
AntiAlias=1

[StyleIcon]
X=(10+#Index#*25)
Y=(10+#Index#*50)

[StyleIconTooltip]
X=([Icon#Index#:X])
Y=([Icon#Index#:Y]-20)

---Meters---

[Icon1]
Meter=String
MeterStyle=StyleBase | StyleIcon
Text=#CURRENTSECTION#
DynamicVariables=1

[Icon1_Tooltip]
Meter=String
MeterStyle=StyleBase | StyleIconTooltip
Text=#CURRENTSECTION#
OnUpdateAction=[!SetVariable Index (#Index#+1)]
DynamicVariables=1

[Icon2]
Meter=String
MeterStyle=StyleBase | StyleIcon
Text=#CURRENTSECTION#
DynamicVariables=1

[Icon2_Tooltip]
Meter=String
MeterStyle=StyleBase | StyleIconTooltip
Text=#CURRENTSECTION#
DynamicVariables=1
OnUpdateAction=[!SetVariable Index (#Index#+1)]

[Icon3]
Meter=String
MeterStyle=StyleBase | StyleIcon
Text=#CURRENTSECTION#
DynamicVariables=1

[Icon3_Tooltip]
Meter=String
MeterStyle=StyleBase | StyleIconTooltip
Text=#CURRENTSECTION#
DynamicVariables=1
OnUpdateAction=[!SetVariable Index (1)]
Preview:
Active Colors.jpg
Drawback:
The obvious drawback with this approach is that while it works for "normal" / "sequential" operations that parse the INI file from beginning to end, this would probably fail on other "irregular" operations, like arbitrarily updating a meter for example, as the #Index# variable will retain its last value and won't correspond to the arbitrary meter that we decided to update.
You do not have the required permissions to view the files attached to this post.
User avatar
Yincognito
Posts: 1610
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature Suggestion] Current Section Index

Post by Yincognito »

Brian wrote:
May 4th, 2020, 4:07 pm
I think in some ways we all need to simmer down a little here. With all that is going on in the world and the stresses of everyday life, I think we need to stop and think about others a little more and try to put ourselves in other's shoes.
You're right, and I apologize - maybe I've been a bit selfish and harsh on this one. While I did my best to bring into the discussion ideas that would be very easy to implement, the other issues on your to do list didn't cross my mind, and they should have, because I understand them. I can put myself in someone else's shoes and I'm actually very good at this, but I'm also honest and when I feel something isn't quite right, I speak about it. Bear in mind that it's not the first time I've come up with suggestions and didn't say the above on the previous occasions, even though they also met a dead end (I'm talking about the suggestions, not about the bugs, that were almost immediately fixed). I'm not particularly looking that my own ideas get implemented, I'm just looking to make things in Rainmeter as good as they can possibly get. Just one opinion of many, as jsmorley said.
Brian wrote:
May 4th, 2020, 4:07 pm
jsmorley spends a significant amount of time here on the forums helping everyone he can get the most out of Rainmeter. Sure, sometimes he gets a little snarky now and then, like we all do - but, he has some incredible patience and cleverness that is just perfect for our community. He is the best of us.
Fully agree - he's the best moderator I know, and contributing with skins, plugins and other programs, like many here. Snarkiness is not a problem, at least not for me. I can take a strong stand, a joke or two, a refusal and such - that's not an issue. An issue would be if there was no logical reason for them - and given the simplicity of the issue on this thread, I felt that his reasoning was "thin" in this particular case, if you know what I mean (hopefully it's not interpreted the wrong way).
Brian wrote:
May 4th, 2020, 4:07 pm
This would have a smallish impact on performance. #CURRENTSECTION# is the black sheep of Rainmeter built-in variables. It requires special handling. We actually have several "workarounds" throughout the code to make it work properly. I also disagree with the "dead easy to understand" part....at least a little. The most basic user will grapple with what "index" means in this case...but, with proper documentation, this isn't really an issue.

On to the "usefullness" part. jsmorley is right, the vast majority of skin authors probably won't ever use this. That doesn't mean it isn't a good fit, or useful in some situations. It's just a comment that is more about "priority" than anything else. The more time we spend on this, the less time we spend on other projects (like proper DPI support).

I think the "trailing index" version of this is the better idea. We may discuss this internally. :D

-Brian
I didn't know that #CURRENTSECTION# is the black sheep of Rainmeter built-in variables, it never crossed my mind, to be frank. Even so, this isn't about getting the black sheep all over again (since this is done already), it's about breaking it apart based on some logical criteria - this shouldn't be an issue, I mean it's just a matter of a single substitution in regex (talking from the user standpoint here). I disagree that the vast majority of skin authors probably won't ever use this though. While this might be true for #CURRENTSECTION# (and I'm one of the authors who almost never uses it), a #CURRENTSECTIONINDEX# would provide an actual indicator on which section of many is "active" in a way that can be used to simplify writing the code.

Trailing index is fine with me, and discussing about this internally is all I could ask - the timeline and other stuff are secondary, as I once said to jsmorley, no pressure, take your time. Who knows, maybe there's a way to "blend" Active Colors' suggestion with mine, although I can't see how it could be done by creating only one additional built-in variable. Thank you. :thumbup: