Theme's and globalizing

[nawmtaronyu]

So I had this idea the other day of consolidating certain variables that are used universally. For example I have several skins, 3 Icon based launchers, an audio switch, time and date text, and system info. Since I like everything to be unique but uniform, that is have similar colour schemes and font type I have set a "Theme.ini" file in my skins folder. this file keeps global settings like a primary and secondary colour, and font type used by all these files that are then linked by @include.

This brought up an idea for developers to standardize certain variables for easy configuring of a theme for other users. Take the Theme.ini file for example, that can be referenced by several skin developers and user have the option to only change the one file and all the skins colour and fonts variables for easy theme's. We can expand by using a global launcher.ini file that does the same thing, so when I decide to use a new different launcher I do not need to reset all the different icons, names, and paths as the new skin links to the global launcher.ini file.

So I bring up an idea for developers to consider and to work together to develop a global @include system so users (primarily those who do not know coding as well as most here) can easily change settings across all skins.

[jsmorley]

We looked at this in some detail in the past, and decided against it. It is just not a good fit for Rainmeter and the way it works.

The highest level in Rainmeter is what we call a "suite", which is really just a root-level folder that generally has many "configs" under it that are all related in some way, like Enigma or Illustro or Omnimo or whatever. The only logical place to have "centralized" options is in include files and image / font / whatever folders in the @Resources folder of that "suite". There really just is no concept of "global" settings that makes sense.

There just is no way we are ever going to "force" standardized variable names for things like WeatherLocationCode or GMailID which might make "some" sense "globally", and most certainly not the thousands of other options like FontFace, FontSize, FontColor or worse yet, something nebulous like LauncherItem1, LauncherItem2. There are a billion possible variables that would need to be considered for this "cookie cutter" approach, and half of them would already have been used in existing skins and would cause conflicts.

We are just not happy with any approach of "telling authors how they have to do things" in skins.

Even if we wanted to change this philosophy, the issue of things carefully being "globally" set by a user either not working with some skin, or worse yet being overwritten by some .rmskin makes the entire thing a logistical nightmare.

It's a reasonable concept in a way, but just not going to happen.

[nawmtaronyu]

Yes that makes sense and I was not thinking of a forced standard but one that people can choose to use or not. To me this makes sense. As I get back into developing skins I rarely publish suites so I will be developing skins with a global theme system. I will gladly allow anyone else to reference my global theme files and systems. I just think this makes sense for end users when using rainmeter.

[jsmorley]

Yes that makes sense and I was not thinking of a forced standard but one that people can choose to use or not. To me this makes sense. As I get back into developing skins I rarely publish suites so I will be developing skins with a global theme system. I will gladly allow anyone else to reference my global theme files and systems. I just think this makes sense for end users when using rainmeter.

It is certainly possible for you to tell folks that they can "use" your @Resource folder for include files (variables) images, or anything else you want to share. Just have them use things like:

@Include=#SKINSPATH#YourConfig\@Resources\Includes\MyInclude.inc

Or

ImageName=#SKINSPATH#YourConfig\@Resources\Images\MyGMailIcon.jpg

You just distribute a .rmskin that installs some dummy skin to Skins\YourConfig, and have your @Resources folder in there. Then tell your fanbase how to get to it.

Just be aware they will not be able to "distribute" a .rmskin that contains your resources, as a .rmskin can only contain one root-level folder, and that if I distribute a skin called YourConfig, installing my .rmskin will entirely blow away your's.

There is no way we can logically make "your" stuff global, who is to say it shouldn't be "my" stuff that is global? or Bob's stuff that is global? And who is to say my stuff shouldn't overwrite your's when a user installs my .rmskin?