sl23 wrote: ↑July 6th, 2021, 12:29 pm
So back to the issue of resource organisation, I believe it is good practice to put suite skin resources in skin folders. Doesn't everyone pick and choose what they like from several suites to get the info they need?
To each his own of course, and there are a million ways you can organize things, but no... There is no way that different skins plucked from different suites are going to have the same look and feel, and I have no interest in using a mess of skins that all have different ways of approaching how they are coded. That just makes maintenance a mess.
I certainly "steal" from other skins or suites if there is a particularly good idea I like. But I only steal the idea. I have hundreds of skins installed in my ..\Skins folder, mostly skins I want to keep around as a reference to a good idea. I don't "use" most of them on a regular basis though. If I do, I will re-write the skin from scratch, keeping the overall look and feel and approach that I use in all my skins. That new skin is either a stand-alone config with its own @Resourecs folder , or added to my JSMeter suite, and any resources needed for the skin go in ..\Skins\JSMeter\@Resources as normal.
Things only go in JSMeter if they are a new idea that I think worthy of "distribution" with my JSMeter10 .rmskin. Otherwise, they are just a stand-alone config. All external files needed by the skin go in the @Resources folder for that config.
I would never, ever have resources just hanging out in the main skin folder. That doesn't make any sense at all to me. I mean, you are just going to HAVE to have an @Resources folder at the root of any config that uses external fonts, which I almost always do, as I really like Fira Sans in my skins. The font files MUST be in @Resources\Fonts at the root of the config. So since I have @Resources anyway, why wouldn't I use it? It helps make Rainmeter start up faster. What possible value is there in having Rainmeter scan all my images, fonts, sound files, .inc @Include files and all that when it loads or is refreshed?
Layouts are used to bring together any number of skins from my JSMeter suite, and any stand-alone configs that I want to use on a regular basis. That is sorta the point of Layouts. Why in the world would I "merge" config A and config B into a single root-level config, when I can just have a Layout that loads both Config A and Config B? The answer is "I wouldn't"...
I have never even bothered "merging" two skins or suites together. It's way too complex to do for my tastes, and the result would always be unsatisfying, messy, and entirely pointless. That is why the entire concept of creating subfolders under @Resources that are specific to a particular skin or suite is, in my personal opinion, a solution looking for a problem that doesn't exist. I guess I could see it if you intend to put together a bunch of skins from other authors, and then "distribute" a single .rmskin that contains all of them. I would never in a million years distribute a skin I didn't write from scratch myself. I actually really hate .rmskins that do that. They are generally just someone stealing a bunch of skins from other authors, adding some spiffy wallpaper image they also stole from somewhere, and distributing it as if they were actually creative. THEY are going to want to "merge" skins into a single root config to support the .rmskin, but guess what... I don't care.
As I said, to each his own, but I ALWAYS just use the .rmskin to install skins I download for testing or to help an author. That way the proper config folder is created, and any 3rd-party plugins are properly installed or updated. I have no interest at all in disassembling a .rmskin and manually copying things where they need to be. The risk of replacing a "new" plugin .dll file with an "old" one alone would discourage me from doing that. By default, .rmskin won't allow that to happen.