Paths and Configs

[jsmorley]

There are two concepts in Rainmeter, that while related, are handled a bit differently. I thought it would be useful to explain a bit how both of them work, how they are similar, and how they are different.

Paths in Rainmeter

There are many times that you need to provide the path to a file in Rainmeter. This might be for example to load an image file, parse a local text file with WebParser, or use !WriteKeyValue to write to a file.

A path in Rainmeter is handled just exactly as it is in Windows or a command window (DOS). A path can be:

ImageName=SomeImage.png : A file in the current folder. In a skin, this would be the same folder the skin .ini file is in.

ImageName=Images\SomeImage.png : A file in a sub-folder of "Images" below the current folder.

ImageName=..\SomeImage.png : A file that is in a folder "one above" the current folder. The ".." construct is an ancient DOS way of saying "go up one directory level".

ImageName=C:\SomeFolder\SomeImage.png : A file that is located in a folder called "SomeFolder" that is directly off the "root" folder of your C: drive. Any path to any folder on your system will work in Rainmeter.

ImageName=C:\Users\YourName\My Documents\Rainmeter\Skins\MySkin\SomeImage.png : A fully qualified path to a file in your Skins folder. This is only going to work correctly on your computer, as YourName won't be the same on someone else's.

Built-in path variables

Rainmeter has several built-in path variables that can make things a lot easier to both load files that are related to Rainmeter, and to deal with making the paths "portable" when used on other systems.

These are explained in Path Variables and Skin Variables.

So just as an example of how you might use them, let's make that path we had above more "portable":

ImageName=C:\Users\YourName\My Documents\Rainmeter\Skins\MySkin\SomeImage.png

could be:

ImageName=#ROOTCONFIGPATH#SomeImage.png

The variable #ROOTCONFIGPATH# would resolve to the Rainmeter\Skins\MySkin\ folder in our example, no matter what system it is run on.

The @Resources folder

One of the most useful things that Rainmeter provides is a way to have an easy-to-find, shared place to put things like image files, sound files, .inc include files, addons, or anything else that is related to your skins, but not just a .ini skin file.

All you need to do is create a folder, under the top-level folder of your skin or suite of skins, called "@Resources".

C:\Users\YourName\My Documents\Rainmeter\Skins\MySkin\@Resources

Anything you put in that @Resources folder, or any sub-folders you create under it, can easily be accessed with the built-in variable "#@#"

ImageName=#@#Images\SomeImage.png

In addition, if you specifically create a folder under @Resources called "Fonts"

C:\Users\YourName\My Documents\Rainmeter\Skins\MySkin\@Resources\Fonts

Than any font .ttf file you put in there will automatically be loaded by Rainmeter and available with

FontFace=FontFamilyName

Extra credit

You can also use any Windows/DOS "environment variable" that defines a path anywhere in Rainmeter. Environment variables are used by enclosing them in "%". You can see what environment variables are available by running the Windows cmd.exe program, and typing "set" in the command window.

ImageName=%USERPROFILE%\My Documents\Rainmeter\Skins\MySkin\SomeImage.png

The environment variable %USERPROFILE% is set to C:\Users\YourName automatically by Windows.

Configs in Rainmeter

The concept of the config in Rainmeter is important to understand. It is used quite often as a parameter to a bang.

LeftMouseUpAction=[!DeactivateConfig ConfigName]

A config has some similarities to a path, but the two should not be mistaken for each other. A config is the way Rainmeter assigns a "name" to a skin. It is NOT a path to any particular file.

A config name can be viewed as "the folder path starting at the Rainmeter Skins\ folder to the folder containing the skin". The best way to explain this is with some examples:

C:\Users\YourName\My Documents\Rainmeter\Skins\MySkin\YahooWeather.ini
-- Config name is "MySkin"

C:\Users\YourName\My Documents\Rainmeter\Skins\MySuite\Clock\AnalogClock.ini
-- Config name is "MySuite\Clock"

C:\Users\YourName\My Documents\Rainmeter\Skins\MySuite\RSS\Google\GoogleNews.ini
-- Config name is "MySuite\RSS\Google"

So to activate that last example with a bang, I would use:

LeftMouseUpAction=[!ActivateConfig "MySuite\RSS\Google" "GoogleNews.ini"]

[iNjUST]

Thanks for writing this! It's very clear and easy to follow.

Two questions/suggestions:

• - Will ever a #CONFIGNAME# variable be added, to reference (using your examples) "MySkin" or "MySuite"? The existing #CURRENTCONFIG# can give you MySuite\Something and #ROOTCONFIGPATH# can give you C:\...\Skins\MySuite\, but there's no easy reference for the Config (i.e. Suite) name, short of a lua script (which isn't that much of a hassle, just seems like an extra step compared to all the existing built-in variables).

• - In bangs such as !Refresh and !Update you can use an asterisk * as a wildcard to refer to "all skins". Would it be possible to implement wildcards in conjunction with config names such as [!Refresh MySuite\*]. If I want to only Refresh the skins in the folder MySkins, the only way that I currently know of is to manually edit Rainmeter.ini to add a Group tag to each loaded skin in MySuite and use !RefreshGroup.

[jsmorley]

Thanks for writing this! It's very clear and easy to follow.

Two questions/suggestions:

• - Will ever a #CONFIGNAME# variable be added, to reference (using your examples) "MySkin" or "MySuite"? The existing #CURRENTCONFIG# can give you MySuite\Something and #ROOTCONFIGPATH# can give you C:\...\Skins\MySuite\, but there's no easy reference for the Config (i.e. Suite) name, short of a lua script (which isn't that much of a hassle, just seems like an extra step compared to all the existing built-in variables).

• - In bangs such as !Refresh and !Update you can use an asterisk * as a wildcard to refer to "all skins". Would it be possible to implement wildcards in conjunction with config names such as [!Refresh MySuite\*]. If I want to only Refresh the skins in the folder MySkins, the only way that I currently know of is to manually edit Rainmeter.ini to add a Group tag to each loaded skin in MySuite and use !RefreshGroup.

Both suggestions are worth considering and we will chew on them a bit and see what happens.

Just as a note, if you want to add a skin to a Group, you can add the Group=GroupName to the [Rainmeter] section of the skin, as well as manually editing Rainmeter.ini. There are advantages and disadvantages to each method depending on how you want Layouts to factor into the process, but there is some flexibility.

[iNjUST]

Just as a note, if you want to add a skin to a Group, you can add the Group=GroupName to the [Rainmeter] section of the skin, as well as manually editing Rainmeter.ini. There are advantages and disadvantages to each method depending on how you want Layouts to factor into the process, but there is some flexibility.

Ah, I wasn't aware of this. But I just threw in

Code: Select all

[Rainmeter]
Group=MyGroup

to a shared/@include'd variables file in my skin suite, and now all the skins that read that variables file also read in the Group.

Slightly off-topic, but based on this, something else I just tried testing was putting a [Metadata] section in the included variables file, but this doesn't seem to work. None of the skins have any information from that included [Metadata].

[jsmorley]

Slightly off-topic, but based on this, something else I just tried testing was putting a [Metadata] section in the included variables file, but this doesn't seem to work. None of the skins have any information from that included [Metadata].

Yes, and that won't be changed. The Metadata is primarily used in the Manage application, which doesn't "run" the skins when it displays the Metadata, but simply "reads" them. Any tiny advantage to having Metadata be shared by skins is not worth the enormous coding effort and processing time required to have Manage resolve @Include files.

[iNjUST]

Hmm, alright that makes sense. I didn't realize the Manage app was reading the skin separately.

I suppose a pseudo-workaround if I actually choose to keep it this way is just putting this in the @include'd file:

Code: Select all

[Rainmeter]
OnRefreshAction=[!WriteKeyValue Metadata SomeKey "Some Value"]

Meh, it works. Not terribly important, but I'll try it out for now to see how I like this new method.

Cheers!


P.S. Sorry for derailing your Tip thread... you can move/remove this conversation to somewhere else if needed.

[jsmorley]

My only caution with @Include files is that in my opinion (and my opinion only) you can take it to extremes and end up with a suite of skins that is very clever and efficient from your standpoint, with 90% of the entire skin code and functionality locked up in a complicated web of @Include files, while being next to impossible for any normal user to wrap their heads around. This makes supporting users with problems or desired changes very difficult, and as an author I think it wise to consider a balance.

Not saying you are... Just something that I run into from time to time with really complicated suites like Enigma and others, where a perfectly reasonable goal of making a suite "easy to use", leads to a suite that is pretty much "impossible to understand or edit".

[thatsIch]

oh my, just wanted to ask the same, if a #ROOTCONFIG# will ever exist. Good thing you take it into consideration since you can already obtain #ROOTCONFIGPATH#

[jsmorley]

oh my, just wanted to ask the same, if a #ROOTCONFIG# will ever exist. Good thing you take it into consideration since you can already obtain #ROOTCONFIGPATH#

We have added #ROOTCONFIG# in the beta today.

http://docs.rainmeter.net/manual-beta/variables/built-in-variables#ROOTCONFIG

[thatsIch]

Finally [!ActivateConfig "#ROOTCONFIG#\Feedreader" "Feedreader.ini"] from another skin of your suite. Nice!