Reusing and changing skins without changing its previous appearance in a layout

[AnryuKen]

The title is a bit long but essentially what I mean is:
*Let's say I used Fountain of Colors Visualizer
*Changed it to Red
*Save it in a Layout (Let's call this Layout 1)
*Reuse Fountain of Colors
*Change it to Blue
*Save it in a different Layout (Layout 2)
Is this possible without affecting Layout 1? Meaning, if I load up Layout 2, it has a BLUE Fountain of Colors while loading up Layout 1, I get a RED Fountain of Colors.

I know about duplicating the skin and renaming the Folders of skins but sometimes changing the colors and variables of a skin also affects the original skin. Is there a way to fix this or do something similar to the process I listed above?

[balala]

I know about duplicating the skin and renaming the Folders of skins but sometimes changing the colors and variables of a skin also affects the original skin. Is there a way to fix this or do something similar to the process I listed above?

Beside dvo's reply I think that duplicating the config is the only solution. For instance rename the Skins\Fountain of Colors config to Fountain of Colors Red, create a new config and rename it to Fountain of Colors Blue. Make the appropriate settings on both. Now you have to include one of this configs into the first layout and the the other into the second layout. Whenever are you loading any of these layouts, the appropriate config will be loaded.
Try out this solution if you are interested and let me know if it does work. I'm not sure it will, but maybe worth a try.

[jsmorley]

There is no way that Rainmeter has any insight into what Layout is currently loaded. From Rainmeter's point of view, there is no such thing as a Layout. There is just the current Rainmeter.ini that is running. Rainmeter doesn't know or care where that Rainmeter.ini came from.

I think the best, and maybe only practical way to do this would be to have a skin that is distinct to each Layout. In that skin(s) set a variable with some name or number of the Layout, so you can test that variable to see what Layout is currently loaded.

[balala]

is there a way to check what kind of layout is loaded ?

As jsmorely said, no, there is not. See his reply above.

[Yincognito]

Oh man, I really really don't like the "no, can't do", "no, there isn't any way to do this and that" kind of answers... That's just an easy way out from a question (just like replies questioning the motive of a question, i.e. "why would you like to do that?", they're lots of 'helpful' people on StackOverflow asking that in the comments and then you don't see any of them actually posting an answer), and it's almost never true, because every problem has at least one solution, not to mention that almost everything is possible, whatever the field being discussed, even more so when it comes to software.

But, that being said, to get to the point ... both things are possible, and the solutions are relatively simple in each case. Now of course, while saying "no can't do" is an easy way out from a question, saying "no, I don't like this" or "no, it's too complicated" is an easy way out of not accepting a solution to that same question, LOL - both these two sides of the coin actually have to do with how much does one want to either find or apply a solution in the first place.

So, assuming folks really want a solution along the lines of the questions:

1. YES, you can load two layouts where some settings (like color, in this case) are different, and you don't need to duplicate the entire skin folder and its contents, only the main .INI that is loaded. The key is making the necessary changes to that .INI file, like, for example, adding a SomeColor=255,0,0,255 (i.e. red) and a SomeColor=0,0,255,255 (i.e. blue) - or their equivalents for the skin - at the end of that config's [Variables] section and saving each modification of the INI as a variant of the skin. Considering the fact that the number of the loaded variant is in fact saved in the layout as the value of the Active option in that skin's section from Rainmeter.ini, when loading the Red or Blue layout the corresponding variant will be loaded as well, assuming the said variant was active when saving the layout in the first place. Now of course, for some skins duplicating the whole skin folder might be easier to do, but generally in "normal" skins such an addition to the end of the [Variables] section followed by saving the variants would do the job, since later variable values in the said section overwrite their preceding equivalents.

2. YES, you can find out which layout is loaded, assuming the saved layouts are different from each other (a very likely possibility in most cases, really, albeit not in this specific one, where solution 1 is suited). All one needs to do is locally parse using simple RegExp=^.*$ WebParser measures both the current Rainmeter.ini and its corresponding Rainmeter.ini files of the desired layouts and use IfMatchActions to compare their contents. One could even compare the current Rainmeter.ini against all the saved layouts from the Layouts folder in the Rainmeter's Settings folder, if the FileView plugin is used.

So yeah, it's possible to do both, and when one option isn't suited, the other is. Like anything else, they do involve a bit of "work" (people nowadays use this term even for the most basic things one does, just to avoid it, LOL), but if you're not happy with doing 'something' to achieve your goal, you might just as well be happy with the "no, can't do" answer, right?

[jsmorley]

Right. I wasn't suggesting that you can't create a way to keep track of what Layout you have loaded. The solution I offered, using a static variable like CurrentLayoutName=Blue Variant or some such is one reasonably simple way to do that. There are no doubt other approaches you can take. I was reacting to the question, which was whether or not Rainmeter had a way to "know" what Layout was currently loaded. In effect some built-in variable like #CURRENTLAYOUT# or something. The answer to that is no.

[Yincognito]

Right. I wasn't suggesting that you can't create a way to keep track of what Layout you have loaded. The solution I offered, using a static variable like CurrentLayoutName=Blue Variant or some such is one reasonably simple way to do that. There are no doubt other approaches you can take. I was reacting to the question, which was whether or not Rainmeter had a way to "know" what Layout was currently loaded. In effect some built-in variable like #CURRENTLAYOUT# or something. The answer to that is no.

Absolutely, if you put it that way. It makes sense, since although you can load a layout, the attributes / properties of the current layout can change in a heartbeat, so in a sense, you can't really be sure that your actual layout of the skin stayed the same as the saved one (which was just loaded a moment ago). What's interesting though, is that one has to use a plugin (yours, to be exact) to find out which skins are loaded in a certain moment in time. One would expect that this information is already available to a loaded skin, at least from a logical point of view. Not saying this is wrong or anything like that, to be clear, I just find it interesting - just like Brian's mention that the built in #CURRENTSECTION# variable was one of the trickiest to implement and workarounds were needed in some cases. Again, something you wouldn't expect - and if we talk about currently loaded / active / running elements, these and the layout discussion bear some resemblance.

P.S. That being said, the questions, as far as I can see, were in both cases if it's possible, or if there are other ways of getting that info, and not necessarily if Rainmeter has a "built-in" way of knowing the answer to that. Me, I was reacting to that side of the question, if it makes sense.

[jsmorley]

Absolutely, if you put it that way. It makes sense, since although you can load a layout, the attributes / properties of the current layout can change in a heartbeat, so in a sense, you can't really be sure that your actual layout of the skin stayed the same as the saved one (which was just loaded a moment ago).

Right. It's why I don't like to encourage trying to do too much with Layouts. Rainmeter really only knows one thing. It knows what is in the currently loaded Rainmeter.ini. Layouts are just a way to save and switch out copies of Rainmeter.ini. Once you do so, and Rainmeter is refreshed, Rainmeter has no concept of, or visibility into, the fact that the current Rainmeter.ini isn't the only one that has ever been used. Trying to do anything programmatically with Layouts is not particularly easy, nor particularly reliable.

[jsmorley]

I would not be opposed in principle to having a built-in way to detect if a particular config or even skin .ini is running, although how to expose that would take some thought. There are some complexities with "variants" that would need to be considered. I would not be in favor of trying to extend that to layouts though, as that would take a great deal of re-thinking the entire concept and approach to layouts.

[Yincognito]

Right. It's why I don't like to encourage trying to do too much with Layouts. Rainmeter really only knows one thing. It knows what is in the currently loaded Rainmeter.ini. Layouts are just a way to save and switch out copies of Rainmeter.ini. Once you do so, and Rainmeter is refreshed, Rainmeter has no concept of, or visibility into, the fact that the current Rainmeter.ini isn't the only one that has ever been used. Trying to do anything programmatically with Layouts is not particularly easy, nor particularly reliable.

Indeed. How about saving the "settings" of a particular skin or skin suite? Wouldn't it be a relatively useful additiion to one of the tabs in the Manage Rainmeter window? I'm thinking of something like the Merge Skins / Variables File in the skin packager dialogs, where you can choose the files that hold a particular configuration for a skin, in the event that the said skin has a ton of settings that can be difficult to replicate on a subsequent loading or installing.

I, for example, use a remotely related way of holding up some settings in my skins, by having two Variables.inc - like files, one containing the current values of the variables and the other containing their "defaults", to which the user can anytime "reset" to, without having to reinstall the skins for that. You know, something a bit more than just the position and their active status. Just asking, no pressure or urgency...