JSMeter10

[Yincognito]

Why not just have them separate? Sorry, but I don't see why would one need to do what you are doing on a regular basis.

I suppose he wants only some skins of a suite, "combined" / "merged" with other skins (individual ones or part of other suites). This can be tricky to do, as it requires either knowing what you need (i.e. the "dependencies" of each skin from the final "product") or dealing with various places where such skins can hold their resources.

One can, of course, activate / load only the skins he wants, it's just that he can't easily "build" a "new suite" with just the required elements. At least that's what I understood from this.

[death.crafter]

Your example above is indeed redundant, as death.crafter said. First, the #@# already means [SkinFolder]\@Resources, so, according to your example, a hypothetical individual (?!) skin named Awesome would be placed in the folder:

Code: Select all

C:\Users\[UserName]\Documents\Rainmeter\Skins\Awesome\

while its resources would be placed in the folder:

Code: Select all

C:\Users\[UserName]\Documents\Rainmeter\Skins\Awesome\@Resources\Resources\Awesome\

Notice how both Awesome and Resources are repeating themselves in the 2nd path above. Not good. Long path, redundant path, messy path - don't go that path.

He rather meant:

Code: Select all

@Resources\SkinName, e.g.

C:\Users\UserName\Documents\Rainmeter\Skins\Awesome\@Resources\Awesome

But anyway. It's redundant.

[bravo-lemur]

One can, of course, activate / load only the skins he wants, it's just that he can't easily "build" a "new suite" with just the required elements. At least that's what I understood from this.

Surely that is what Layouts are for??

[sl23]

I suppose he wants only some skins of a suite, "combined" / "merged" with other skins (individual ones or part of other suites). This can be tricky to do, as it requires either knowing what you need (i.e. the "dependencies" of each skin from the final "product") or dealing with various places where such skins can hold their resources.

One can, of course, activate / load only the skins he wants, it's just that he can't easily "build" a "new suite" with just the required elements. At least that's what I understood from this.

This is exactly the idea, yes.

I could just install every skin available and use layouts as mentioned, but I don't really want hundreds of skins installed just to use a select few. Besides, I always end up editing a skin to what suits me.

I prefer minimalist approach and have only 4 skins loaded.

1. Sidebar with clock and date, tool tip for Windows version and c drive info. Meters to show drive stats with click to open and remove. Shutdown restart etc buttons.
2. Taskbar with CPU and RAM stats. Media player controls and stats. Download stat. Connected USB drives appear as letter for quick open disconnect. Parts hide and show when media player opened and closed.
3. Mini launcher switches between two config's for apps and emulators. Both config's identical apapt from that. They have a volume digit meter which left click sets at 25 right click sets at 80 middle click mutes. Also have a VU meter.
4. Web search skin.

So having lots of skins isn't my way. Generally, I grab what I need and use it more functionally than aesthetically. Although I've made them simple to look at they are quite pleasing too. Not too much with just the info I require.

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?

[jsmorley]

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.

[sl23]

Oh no, I appreciate that, I wouldn't either, but it is the moving of skins to a central 'suite' folder that then makes it easier to adjust them to your liking. Like I said, I'm not fluent in coding Rainmeter, but I still have a great deal of enjoyment finding ideas that I can adjust to my own preference, Surely there are other users that have similar abilities as me that may benefit from a similar workflow?

I thought that was the central idea to Rainmeter, the ability to share and use others ideas and code? Have I broken some rules by doing this then? Apologies if I have, as I said I thought it was the way of Rainmeter. I definitely never realised it was considered a bad thing to share skins that have been edited. Though I do always change things quite considerably, even if using the basic idea. Not to try and make everyone think I'm great at coding or anything, just to share and give others ideas on how to do things differently. Least that's my pov. In future I will be more careful and considerate as to what I share.

I have to admit, I'm not keen on the Layouts idea as I personally found it too easy to lose my current layout and find it confusing how it works. As in, what is saved, how to include certain skins while not others, etc. The point of 'merging' is simply to create my own kind of 'suite' rather than have stuff 'loose' in the Skin folder I suppose. Anything outside my suite is used purely for testing.

You are the developer and as such don't even need to think about disassembling skins, people like me who don't have your knowledge and ability can't do what you do. So the alternative is to learn from others by disassembling skins Then I take the bits I need and can make it into something I want. Sorry if I offended you, like I said, I just thought that was the idea of this skin thing, to share ideas and have fun coding Rainmeter.

I understand the benefits, though I didn't know about the faster loading, it was just an idea and me voicing my 'gripe' about how things are just thrown in there. It seems no-one has the same problem as I do with this, so I'll just live with it. Thanks for all your comments,

[Yincognito]

He rather meant [...]

I know - I just mentioned the "double redundancy" just in case he meant exactly what he wrote.

Surely that is what Layouts are for??

For sure, you're right. But if you use X skin from XXX suite, along with Y skin from YYY suite (and a bunch of similar), with layouts you still have to keep the unneeded skins in the XXX and YYY suites, along with all their unneeded dependencies (plugins, scripts, images, etc). Still messy, in a way - just like having multiple skins from different suites (or even individual), but with different visual styles and implementation approaches, like jsmorley said. As mentioned by both jsmorley and me, the best thing to do is just start from scratch and create the desired "mixed new suite" - unfortunately, not everyone is able or willing to do that, as it involves a fair amount of work and knowledge, hence the discussion above.

I prefer minimalist approach and have only 4 skins loaded [...]

Yeah, what I meant here is the skins' actual names and suites they belong to (if they do, that is). With such a list, maybe you could get help to mix them together properly in a specific thread about this. Just saying...

So back to the issue of resource organisation, I believe it is good practice to put suite skin resources in skin folders.

Even if such a thing was supported by the devs, you'd have two problems:
- it's too late, supporting anything but the current system will affect backward compatibility (in a lighter way than other such situations, but still)
- you can't convince or force all the skin designers to do this (not sure if you can create a poll here on the forum, but the result of such a poll would be different than what you'd like, I'm pretty sure of that; I would vote against it too as I'm quite happy with the current system, although as I mentioned, I completely understand being minimal and only keep what you actually use, since I'm like that too)

Doesn't everyone pick and choose what they like from several suites to get the info they need?

Not really. When folks want skins to look and feel exactly as they envision (and not otherwise), they'll settle for individual skins and skip suites altogether. If folks want skins in a similar way as they envision (in other words, are willing to compromise), they'll settle for the skin suite that has the most of what they want. If they aren't happy with either and they really mean what they want, they'll try to build their own suites. I'm talking personal use here, because otherwise people will try (and like) a lot of skins or suites because, to be honest, there are really nice looking (and probably nice functioning) skins and suites out there.

[sl23]

Thanks for your time, Yincognito, I realise I am indeed a special case, so I'll just keep quiet about this one now

[Yincognito]

Thanks for your time, Yincognito, I realise I am indeed a special case, so I'll just keep quiet about this one now

Okeydokey, then.

[Bribeired]

@jsmorley Beautiful skin. It does not snap on edges?