Suggestion for new bangs: !SetKeyOption and !SetKeyVariable

[MattNY177]

I was reading through some old threads and found the following quote from jsmorley regarding sharing variables between skins:

You can of course use both... !SetVariable to dynamically set the variable in one or more other skins without refreshing, and !WriteKeyValue to make the change "permanent" if that is desired, so when any or all of the skin are in fact reloaded or refreshed, the new variable value is "shared" by all skins. -- (Source: https://forum.rainmeter.net/viewtopic.php?t=18230)

The more I use Rainmeter, the more I find myself needing to do both of these -- change a variable, then update a skin to reflect it (without refreshing), but also make that change permanent so it persists when the skin is refreshed.

I would propose combining these two functions to help minimize the code necessary to achieve this desired outcome:

!SetKeyOption = !SetOption + !WriteKeyValue
!SetKeyVariable = !SetVariable + !WriteKeyValue

Thoughts?

[jsmorley]

I'm not opposed to the idea in principle, but it might be hard. or at least clumsy, to implement.

!WriteKeyValue and !SetOption have two entirely different things they work on. !WriteKeyValue is based on any physical "file", and !SetOption / !SetVariable are based on any currently running "config". To create a single bang that addresses both of these at once might mean a syntax that is almost more confusing and hard for skin authors to write as the longer, but straightforward use of two bangs is today.

It would certainly mean changing how "default" options are used in the bang(s), as today the default for !WriteKeyValue is the current skin .ini file and the default for !SetOption is the currently running config. You can't easily have two optional, default parameters in a bang in our current method of parsing bangs in the code. So I suspect you would always have to spell out the file to write to and the running config to impact, and that would be regrettable.

!SetKeyOption SomeSectionName SomeOptionName "Some Value" "#CURRENTPATH#SomeFileName.ext" "Some\Config\Name"

It wouldn't be difficult to default "both"

!SetKeyOption SomeSectionName SomeOptionName "Some Value"

But a challenge, and probably confusing, to default "either / or". Parameters in bangs are "positional" in Rainmeter. it could be doable, but it would mean that to define the "config", you would HAVE to first define the "file". There is no such thing as a "default" parameter indicator in bangs today, and I would be hesitant to try to introduce that concept.

That concept of a "default" placeholder in parameters does exist today, but only in specific isolated cases, like the Shape Meter. In that case, we use the * character as the placeholder, but that would never, ever be possible in a bang, where * already has a specific meaning.

This seems like an idea that feels really good on the surface, as in specific cases, granted probably often, where you are writing to the current skin .ini file, and at the same time want to make a change to an option or variable in the current running config, it would make things shorter and has a lot of charm. However, it seems like it would only be good for that specific case, and would quickly devolve to something a lot less charming when the circumstances are different.

[balala]

I'm not opposed to the idea in principle, but it might be hard. or at least clumsy, to implement.

And useless, in my opinion. When we write a bang, if needed we can write two as well. No need to add new bangs for this. Don't complicate things, if not needed...
As said, just my opinion.

[jsmorley]

I'm not sure "useless" is the term I would use, as I said, I can see the charm in the idea. I'm just not sure it passes a cost / benefit analysis with flying colors. As always, the devil is in the details.

I'd be more inclined to this if !WriteKeyValue and !SetOption / !SetVariable were more "related" to each other. They really aren't at their core. They have two very different purposes.

[balala]

I'm not sure "useless" is the term I would use, as I said, I can see the charm in the idea. I'm just not sure it passes a cost / benefit analysis with flying colors. As always, the devil is in the details.

Yep, maybe "useless" indeed isn't the best term, but anyway I think doesn't worth to add such new bangs, since everything can be done through two already existing bangs.

[StArL0rd84]

After reading this, a tiny hope of it being implemented lives.
But would be nice with a more definite answer to the topic.
Could potentially slim down our coding by a factor of a lot...