Global Variables Idea

[cwfrizzell]

Checking out a lot of the newer and more established skins, I noticed I was continually entering the same information (weather location, gmail username, etc). It dawned on me certain variables like these are universal across skins, so why not have a Rainmeter global variables text file, with a simple UI a la Config.exe, users can load common variables into just once? All user-built skins could then reference that particular file for that information if/when required.

Thoughts?

[smurfier]

I believe this would be at least interesting. Have a third "settings" file, or maybe incorporate this into Rainmeter.ini. Once these "variables" are set then they could be used in any skin just like the built-in variables currently are.

There would just be one large issue. What would happen if these values are not set? Would there be default values or would the skins using the variables just not work?

[cwfrizzell]

I believe this would be at least interesting. Have a third "settings" file, or maybe incorporate this into Rainmeter.ini. Once these "variables" are set then they could be used in any skin just like the built-in variables currently are.

There would just be one large issue. What would happen if these values are not set? Would there be default values or would the skins using the variables just not work?

I think the Rainmeter.ini is a good place. It could simply come preloaded with default variables. The user would personalize the variables as required through a user global variables config.exe. This would allow skins to function from the outset, provided the default variables facilitate their operation (a default Gmail username of "username" probably wouldn't allow a GMail skin to connect, but it would open).

[santa_ryan]

This has been discussed and dropped as too complex and error-prone.

See Poiru's response.
http://rainmeter.net/forum/viewtopic.php?f=14&t=7281

It's not practical to do this as a true rainmeter feature.

However, rainmeter essentially already has this built in... using the almighty @INCLUDE function for variables
Make yourself a file with all the variables you want, and then do an @include inside the settings file. All you have to do is then set the variables to your own variable.

E.G

Code: Select all

[Variables]
@Include #SkinsPathMyVariables.inc

GmailUser=#GUser#
GmailPassword=#GPass#
Text1=#MC1#
Text2=#SC1#

However, you could break some skins by doing this if your variable is the same name as another. Just a heads up!

[Scolex]

You can do this with an @include file.
opps: I guess that had already been said went to read the linked post and didn't finish reading the above post.

[cwfrizzell]

Thanks for the responses. I'm already very familiar with @INCLUDE. While it gets people there for a particular skin wuite, unless skinners are designing around the same inc file, this doesn't really cover things from a global perspective.

Still, I understand the potential for too much complexity and confusion.

Moving on...

[poiru]

This has been discussed many times and we've always concluded against it.

[cwfrizzell]

This has been discussed many times and we've always concluded against it.

Thanks for chiming in Poiru. I read through that thread. It's not exactly the idea I conveyed, or at least attempted to convey. I'm not interested in global variables for things like font size; that, in my opinion, would simply stifle skinner creativity. I'm more interested in accessibility and usability.

For the sake of debate, and to educate me a bit more, I ask this question of the experts here:

How difficult would it be, from an overarching Rainmeter programming perspective (not a skinner's perspective), to implement a global variable.inc file that users could use to house things like their personal weather codes, e-mail account information, facebook info, twitter, etc, then have applicable skins simply reference that global varible.inc file via the @INCLUDE action?

I'm no expert by any means, but on the surface this seems fairly straightforward. I understand skinners would have to make modifications to existing skins, but this is nothing new to those who have skinned Rainmeter for any length of time.

To be honest, I'm looking at this from a user perspective, to simplify my experience as a user. I try skins, switch between skins based on my mood, and generally muck around to learn how some really talented skinners get these often fantastic results. The problem is, as a user, it is frustrating having to constantly update the same basic user information time and again with each new skin/suite.

From where I sit, the @INCLUDE action was a big leap for skinning. The config.exe was a big leap for both skinners and casual users. The Illustro skin provided a nice platform for would-be and novice skinners. I think the global variables.inc, properly implemented, would further expand Rainmeter's audience by making a great program that much more accessible to the masses who might have little technical skill or desire to dig into skins, but enjoy the idea of trying and using new skins without the hassle of re-entering basic information.

Call me crazy, but it makes perfect sense to me. Regardless, I truly appreciate the feedback.

[Chewtoy]

It actually shouldn't be that hard at all.
You could probably make it so there are some GlobalVariables.inc that's in the same folder as rainmeter.exe and have some global variables that rainmeter loads to each skin, but still making variables that are defined with @include or in the skin itself top priority.
This would however require that we use some global name that we are to tell everyone to use.
So, while it might make it easier for the end user, you might very well hammer the creators creativity by forcing them to use specific variable names.
Though one could argue that instead of using ## for the global variables and using say, ¤¤ instead, you would not get any conflicts. The variables in that come with the skin could even be linked to the global variables.
But still, how many global variables should there be? Why would we force this upon users? Using some global variable might not work with a skin, then why load them? And so on...
While it might sound quite nice in theory and it would be less frustration for end users to change skins so they look.. just like the previous one they had... It feels more to me, as a coder, like we are saying "You have to code like this!". And that is fine as long as it's so Rainmeter can read the code. but when you say how I should name my variables, then you are messing with my work.

[cwfrizzell]

It actually shouldn't be that hard at all.
You could probably make it so there are some GlobalVariables.inc that's in the same folder as rainmeter.exe and have some global variables that rainmeter loads to each skin, but still making variables that are defined with @include or in the skin itself top priority.
This would however require that we use some global name that we are to tell everyone to use.

First, thanks for your feedback! I understand and agree with what you're stating. This is exactly what I'm getting at.

So, while it might make it easier for the end user, you might very well hammer the creators creativity by forcing them to use specific variable names.

I respectfully disagree. How much creativity is lost by defining a global variable for a Gmail username as "username" for example? Looking across recent and popular skins/suites, I'll wager most skinners are using an almost identical variable already.

But still, how many global variables should there be? Why would we force this upon users? Using some global variable might not work with a skin, then why load them? And so on...

Looking across the current skin/suite spectrum, I see several popular, nearly ubiquitous, configs including Gmail, weather, RSS Feeds, and app and folder launchers. Up and coming configs include Facebook and Twitter. In nearly every instance (save some app/folder launchers that skinners hard code), the config REQUIRES the user to provide user-specific information; information the configs obviously view as variables. Having the ability to simply define these variables globally for Rainmeter in general, with a simple one-time user entry method a la config.exe, rather than having to do them for each skin one comes across, simply makes sense to me.

As to forcing them upon users, I don't see it that way. If one looks at Gnometer, for example, the weather code is preloaded with a "default" variable. The user doesn't have to change the variable, nor does the user have to use that particular config. It has no impact on the config or the user. Should the user choose to use it, however, then the user must enter a weather code for the Gnometer config. Now if the user chooses to switch over to the Pragmatic 1.0 weather config, for example, the user has to enter the same weather code into that config. Stepping back and looking at both suites, they both utilize @INCLUDE to supply the user's weather code across several variations. I'm simply advocating to take the next logical step: do this globally.

Of course, there is some merit to the argument that in this weather example, creativity is limited to a particular weather information source. But what's to stop one from identifying the popular weather information sources and establishing a global variable for each? Even with some lesser known sources left out, this does not stifle creativity because a skinner is still free to create skins using existing methods.

While it might sound quite nice in theory and it would be less frustration for end users to change skins so they look.. just like the previous one they had... It feels more to me, as a coder, like we are saying "You have to code like this!". And that is fine as long as it's so Rainmeter can read the code. but when you say how I should name my variables, then you are messing with my work.

Just to be clear, I'm simply talking about user-specific variables like weather codes, Gmail usernames, and the like. I have absolutely no desire to box in this community's talented skinners by forcing them to use some common design-specific variable. That said, I do not consider variables such as Gmail user name to be design-specific.

Hopefully, this clarifies what I'm talking about. I don't see this as a hindrance to skinners or creativity. I do see it as a standardization of some extremely common user-specific variables, as well as a simplification of the Rainmeter experience from a user's perspective.

Thanks again for your feedback, Chewtoy!