Step 1
At the root will be a Variables.ini next to Rainmeter.ini. The Variables in this file will be considered "global", meaning any skin author can use the variables that we have defined here in their skins. This would be used for things like #AccuweatherLocation# so the user only has to enter the location once in Variables.ini and it is available to all skins that use #AccuweatherLocation#.
I would also suggest moving ConfigEditor to this file rather than Rainmeter.ini. As it is now when we distribute themes, the users will have to manually change their ConfigEditor= on each .thm. Moving the Skinpath= there might also be a good idea. (Why isn't it SKINSPATH in Rainmeter.ini like the variable name?)
Example ini
Code: Select all
[Variables]
Skinpath="C:\Program Files\Rainmeter\Skins\"
ConfigEditor="C:\Program Files\Notepad++\Notepad++.exe"
AccuweatherLocation=28212
Step 2
We'll call this "External Skin Variables" for lack of a better term. This would be at the skin author's discretion. Any skin folder containing a Variables.ini would apply those variables to all skins in that folder and any subfolders. I'll use Enigma as a quick example. If Enigma\Variables.ini exists...
Code: Select all
[Variables]
FontColor1=255,255,255,200
FontColor2=255,255,255,150
Step 3
Skin level variables in individual skins would still be in place, and would also include any applicable variables from the "external" Variables.ini. This is to insure that moving or copying a skin from it's root folder does not render it useless as it will be looking for nonexistent variables, if they aren't included.
If a user wanted to change the FontColor1 of only one skin they would have to change the variable name in that particlar ini.
I think that about sums it up. Any ideas or suggestions or glaring holes in the logic that I missed?