I'm short on time, so I'm just going to post my chat log... I may flesh out the idea later, but I want to see what people, gurus, and other Devs think about this idea...
[15:58] <gsch-Zzzz> folders should be able to have a "template.ini " file that defines elements that are common to all .ini files in that folder
[15:59] <gsch-Zzzz> thereby simplifying variants of skins
[16:00] <gsch-Zzzz> the "template.ini " file would be inherited by sub-folders as well
[16:00] <gsch-Zzzz> thereby making a CSS like abstraction of variables possible
[16:04] <gsch-Zzzz> imagine changing color schemes for a whole theme, by editing only one file
[16:04] <Alex2539> if you have one at the top that's overriding settings in skins to which one term has a different effect... bad things
[16:05] <gsch-Zzzz> there would be a heirarchy like in css
[16:05] <gsch-Zzzz> code in a file always overrides template code
[16:06] <gsch-Zzzz> it would lead to some tech support issues
[16:06] <gsch-Zzzz> but is in file code always overrides... it shouldn't be too bad
[16:09] <Alex2539> on the surface, it looks like it would be really, really helpful to both the developers of multiple skins, as well as the end user who would have less code to rummage through just to set their weather code
[16:11] <gsch-Zzzz> ooh, i didn't even think of that, if developers used standardized names, you could customize every suite with one file
[16:12] <gsch-Zzzz> ooh
Honestly I love this idea, the skin I'm working on now actually has me copy,pasting "base" code to multiple files (this is to make it so there isn't a single very very cluttered ini) and this idea would once again change how rainmeter works.
This isn't to say that this is a bad idea, it's very good. I mean if I had a base code and in another skin I simply at the top call inherit base.ini and I get all the variables measures and meters from that plus the ones in the current.ini it would be amazing.
Though, the tech support in teaching users that to modify somethings you have to go to the base code, you have to correctly interface the base with the child's, let alone what kind of inheritance we would use, would be insane.
I suppose ultimately it's up to the dev's. I mean right now what there working on (tweaking in the current beta) is already leaps and bounds about even v1.0 so it truly comes down to if they can/want to make this a reality. Because honestly I'm not sure if they would want to. This adds another vector of complexity to rainmeter that they might not want to add lest it turns off the casual user, which is what makes rainmeter so cool in how easy it is to pick up and how hard it is to really tax and get everything out of it you can.
i'm gonna try to implement this myself, it doesn't really sound hard to do though I only looked over the source for about 20 minutes. It shouldn't be too difficult, read the base ini file, then read the new one updating variables and adding meters/measures. This would have to be some recursive thing that would load base files of base files maybe.
Fine for suites. Probably not as useful for the way I and I suspect many use Rainmeter, which is a mixture of homebrew skins and skins from DevArt from a variety of authors all with their own way of doing things. My skins are almost never in a single folder tree, and are tied together only by the fact that they happen to have "Active=1" set in Rainmeter.ini.
Interesting concept, but I wonder about the "User Friendly" Implications
Remember that Rainmeter is an advanced tool, and we have all seen good software get user friendlied to death.
Although I must admit I would be interested to see where such a concept could go.
i figured I'd elaborate on reasons for this inheritance, as well as propose an alternate or possible additional option:
1) many skins have multiple variants or configs that switch when actions are taken, such as buttons that expand (moxa-weather's 4day expandable, vasillo for example) these variant skins often duplicate the entirety of the original skin, with only slight variation (dragonmage's context menu configs for sputnik are another example)... with an inheritance, these config variants/sections would be much simpler and more logical to code and edit...
2) with suites we need to remember that many users will only ever use a suite of skins, and making color scheme (for example) more simple to edit would be a dream for many users...
3) the constant complaint about rainmeter vs samurize from the masses revolves around the "millions of ini files to edit".. anything that can help there without sacrificing power is a good thing... as long as it's logically implemented...
4) heck, separating some of the design from functionality not only makes the code simpler and more logical, it makes it more easily machine parsed and machine creatable... it would make the job of config tools like the settings screen by jsmorley and kaelri operate in O(n) time, rather than theoretical O(n!) time (for non comp-sci people, thats a very good thing)
5) it looks like CSS and Javascript... that may seem like a weird positive point, but you gotta remember that a large portion of rainmeter users are from the computer-graphics section of the world, rather than programming or windows IT crowd... the most likely languages for them to have seen are HTML, CSS, and Javascript... the form/function divide that is normally followed there is a good way to hide the nitty gritty regexp and coding stuff, while presenting easy access to display/design options
6) THIS SPACE INTENTIONALLY LEFT BLANK
------
on the topic of how to implement.
an inheritance tag is one option
an include tag (with support for include2, ect) that takes a relative path is another
the third option is to use both... inherited code is given hierarchy by level of nesting (root code is overridden by code in a subfolder, ect...), included code has hierarchy over inherited code, include3 has hierarchy over include2 has hierarchy over include(ect..), code in actual config file has hierarchy over all.
I personally prefer the third option, as the hierarchy is simply a matter of getting the order of the parsing loops in the right order in the code, and it provides more power/flexibility to multiple coding styles.
This would be a most excellent idea to implement. I've quite a few scripts that share common variables and would benefit hugely from a common file that could, in some way, be included as a part of all of them rather than having to cut-paste into new ones and, most annoyingly, having to update each and every one if something new needs be added.
By-the-by..is there a "wall" of some form that the dev's keep that might indicate what they're currently working on and what might be up for later inclusion...?
yeah, either an auto-inherited include file, or having a command to specify an ini to include for a given skin would be invaluable tool for a developer like myself. It's done wonders for the web design world and php, along with css, etc. It means the developer could have simpler codes, seeing as they wouldn't have to have every tiny configuration in every file, and it means that skins could be themed easier by changing attributes across all elements of a theme.
