It is currently March 28th, 2024, 10:17 am

JSMeter10

A package of skins with a "theme" or by a single author
User avatar
sl23
Posts: 1140
Joined: February 17th, 2011, 7:45 pm
Location: a Galaxy S7 far far away

Re: JSMeter10

Post by sl23 »

Thanks , I get all that. I think it's my misunderstanding. I dislike installers of any kind and it's extremely rare that I use one. They just put stuff anywhere without users knowing where it's going. I'm talking general app here, not Rainmeter.

So when it came to Rainmeter, I again had the same issue. Not knowing what's installed or where. Let's say I install a couple of skins but it installs plugins without me knowing, they're left there and I don't even know it.

Let's take the issue of apps sharing resources. Many times when I used to install apps via their installer packages, they go all over the system, but the problem arises when you're asked upon uninstallation whether to keep certain dependencies as other apps may use it. You're left with junk if not, or broken apps if there is.

Essentially, it's about organisation preferences. But single skins have no need to use the resource folder and imho, shouldn't. Suites, I can now understand, they are like a self contained set of skins. Let's say a skin uses #@#fonts, why? Why not just use fonts? It serves the same purpose. If all the resource files are just simply placed in the resource folder, that's when it can potentially become an issue.

I know none of you will see my point of view so I'll just leave it at that. Apologies if I came across the wrong way, I don't mean to sound antagonistic, just trying to get a point across that shared resources aren't always a good thing. Probably I'm just a special case! :bow: :D :rofl:
User avatar
Yincognito
Rainmeter Sage
Posts: 7017
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: JSMeter10

Post by Yincognito »

sl23 wrote: July 4th, 2021, 9:04 am Thanks , I get all that. I think it's my misunderstanding. I dislike installers of any kind and it's extremely rare that I use one. They just put stuff anywhere without users knowing where it's going. I'm talking general app here, not Rainmeter.

I know none of you will see my point of view so I'll just leave it at that. Apologies if I came across the wrong way, I don't mean to sound antagonistic, just trying to get a point across that shared resources aren't always a good thing. Probably I'm just a special case! :bow: :D :rofl:
Don't be so sure you are the only one thinking this way... :D

Personally, when someone needs help with X skin and provides a .rmskin link (i.e. a skin I don't want to keep after helping out), I will very rarely "install" the skin the usual way and just add a .zip extension to the .rmskin one in order to extract only the problematic .ini or .inc file(s). As a matter of fact, most of the times I won't even need to, as I'll view the contents from within the archive and just paste it into my "test" skin or copy the needed ini / inc files and start from there (I use a file manager that makes these easier).

As far as the Resources folder and its use by all the skins in a suite is concerned (I guess this is what you originally had a problem with), I understand your view but I'm not at all bothered by it. Sure, I didn't have to break up suites to make a certain skin (and probably won't have to) since I almost always started from zero when writing stuff in Rainmeter, although I might have took some more or less abstract "concepts" from one skin or another, but this is made easier by the fact that even with a "shared" Resources folder between skins from the same suite, the file names usually do offer some sort of indication of which skin they belong to (e.g. weather images will most likely be named in a way you can figure out quickly that they are used by the weather skin, the .inc files and where they are needed are quite easy to spot through the @Include lines, that kind of things). I'm also one of those "bad" skin developers who doesn't bother to create a thousand subfolders in @Resources, one for script, one for images, one for .inc-s and such, I just throw them all there and forget about it.

Bottom line, there are ways to relatively quickly identify the relations between resources and the code, IMHO. It's not so bad as it seems.
User avatar
sl23
Posts: 1140
Joined: February 17th, 2011, 7:45 pm
Location: a Galaxy S7 far far away

Re: JSMeter10

Post by sl23 »

I see what you are saying. Many skins though tend to have abstract names for the skins graphical elements. I tend to now keep my own skins self contained as I've found that shared resources can be a pain trying to remember which skins use which graphics.

This tends to be more an issue when having older versions that I don't want to get broken.

Just as a tip, have you ever tried universal extractor to extract files from skin packages? I use it to unpack everything. As I only use portable apps, it helps when updating them or finding new apps and testing for portability.

Anyway, sorry for creating a discussion on this thread. I really like the suite. I won't ever use someone else's suite, I like to make my own even if I'm not quite good enough to do it from scratch! :D

All the best
User avatar
Brian
Developer
Posts: 2673
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: JSMeter10

Post by Brian »

I just want to chime in here and point out a couple of things from an efficiency standpoint.

The very first item mentioned in the docs for @Resources talks about "scanning" for items during loading. When Rainmeter loads, it scans each folder in your skins folder and builds an internal "registry" of available skins. Sure, it only looks for .ini files, but it traverses each item in every folder looking for those files. If you install a lot of skins (especially suites with a lot of images, include files, etc.), this can take time. The @Resources folder is totally skipped during this scanning, meaning you can place your non-ini files in there, and Rainmeter will load faster. This scanning is done when Rainmeter starts, but also when "Refresh All" is used (or !RefreshApp) or when the "Create new skin" function is used.

Also, loading fonts from the #@#fonts folder happens automatically without the use of using the LocalFont, which is deprecated and only supports true type fonts .ttf. #@#Fonts supports both true type .ttf and open type .otf fonts.

Also, custom cursors can only be loaded from the #@#Cursors folder.



Anyway, the use of the @Resources folder is totally optional and it will stay that way. We pride ourselves on user flexibility and backward compatibility with older skins.

In a way, this discussion can remind skin authors to organize their "resources" a little better for those users who choose to utilize just 1 particular skin within a suite.

For example: Let's say you have 10 different skins within your suite. Each skin uses 10 images, but they do not "share" those images from skin to skin. It would probably be better to place the 10 images for each skin in their own folder. Something like this: #@#Skin1\Images, #@#Skin2\Images, etc.

Or if you do share items, place them in a "shared" folder.

Code: Select all

MyAwesomeSuite
  #@#
    Shared\
      Images\
        shared_image1.jpg
        ...
        shared_image10.jpg
      Includes\
        include1.inc
    Skin1\
      Images\
        skin1_image1.jpg
        ...
        skin1_image10.jpg
      Includes\
    Skin2\
      Images\
      Includes\
  Skin1\
    skin1.ini
  Skin2\
    skin2.ini
Anyway, just some things to think about. Obviously there is no "right" way of doing things.

-Brian
User avatar
Yincognito
Rainmeter Sage
Posts: 7017
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: JSMeter10

Post by Yincognito »

sl23 wrote: July 4th, 2021, 1:45 pmJust as a tip, have you ever tried universal extractor to extract files from skin packages? I use it to unpack everything. As I only use portable apps, it helps when updating them or finding new apps and testing for portability.
I didn't try it, and the reason is simple: the file manager I use already functions as a "universal extractor" of sorts, in such situations - it has a Packer tab where one can use either "built-in" plugins / extensions or "custom" ones created by other users or not included in the official build, similarly to how Rainmeter plugins work; all it takes is an Enter or double click on the archive. It isn't that difficult to rename some file to appear as an archive in the case of a .rmskin, it's done using a simple hotkey combination anyway. That being said, if I wasn't using (or didn't know about) this already, I would for sure use such an universal extractor, I'm all for one size fits all principle, as long as it's done properly and flexibly enough. I rarely have two programs that do the same thing, I'm allergic to redundancies. :lol:
sl23 wrote: July 4th, 2021, 1:45 pmAnyway, sorry for creating a discussion on this thread. I really like the suite. I won't ever use someone else's suite, I like to make my own even if I'm not quite good enough to do it from scratch! :D
Nah, I think you misunderstood either mine or someone else's post(s) here. Personally, I didn't mean that breaking, combining or taking ideas from other suites was wrong (as long as it's fairly permitted, credited and all that common sense stuff) - I just tried to convey that I'm not really a fan of such techniques when it comes to my own skins, for two reasons: my satisfaction of being able to make it all work is lesser than when starting from scratch, and the implementation attempt and effort might prove to be more of a "messy" job for the exact same reasons you mentioned (similar example, installing and upgrade a volatile software as opposed to a clean install). For the latter reason, I believe that starting clean is clearer, more straight-forward and you only have to understand your code compared to trying to figure out multiple skin codes or structure that were made by someone else. That's all. In the end, you do as you wish and you choose the solution based on various particularies that suit the said scenario best. No need to feel sorry for discussing this and stating and defending your view, because it's logical and understandable in many ways, so relax. ;-)

As Brian said:
Brian wrote: July 4th, 2021, 3:51 pmIn a way, this discussion can remind skin authors to organize their "resources" a little better for those users who choose to utilize just 1 particular skin within a suite.
This is a valid point. Me, I admitted I poorly managed this aspect and just threw every resource in that folder, but I did name the files in a way that makes it clear whether they are "general purpose" aka shared resources or specific to a certain skin in the suite. As for different types of resources placed together, a simple order by the extension of the files (a click or two away, even in plain Explorer, as far as I recall, and the default in my file manager) instantly clarifies that aspect. Putting stuff in separate folders would have been more inconvenient for me as a skin designer, since if I changed my mind during the coding process regarding resource allocation to various skins in the suite (unlikely, but still) I would have had to move things again, recheck or change paths and so on. It's probably about striking a fair balance between clear and efficient organization.
User avatar
sl23
Posts: 1140
Joined: February 17th, 2011, 7:45 pm
Location: a Galaxy S7 far far away

Re: JSMeter10

Post by sl23 »

Thanks for your comments...

I have to say first that I misunderstood, when I posted originally, how the skin folder and .rmskin packaging worked never having used it.

I completely agree that for a suite of skins, this resource folder makes perfect sense. But in a single skin, I personally think it a 'better' way to add a subfolder for all material. The reason being that although the .rmskin packaging is designed to install, I believe, into the Rainmeter/skins folder, users may wish to edit and use the skin in their own suite, as I tend to sometimes. Examples being TimerNixie and the WebSearch (forgive me, I can't recall it's original name,) skin I recently had help with. Both were simple demo skins, with little if no items in @Resources, which made it easy to adjust. Some skins like Orrery, for example, have kept all data inside the skin folder. But others just place it all into the resource folder directly.

So my original 'gripe' is really a request I suppose that future skins, not part of suite, have any resources placed in subfolders:
#@#Resorces/Name_of_skin

I think Rainmeter is a fantastic app and can be very addictive as it's a lot of fun to mess around with. I'm thinking of having a go at my own suite. :D
User avatar
death.crafter
Rainmeter Sage
Posts: 1399
Joined: April 24th, 2021, 8:13 pm
Contact:

Re: JSMeter10

Post by death.crafter »

sl23 wrote: July 5th, 2021, 5:50 pm So my original 'gripe' is really a request I suppose that future skins, not part of suite, have any resources placed in subfolders:
#@#Resorces/Name_of_skin
I still don't get you bud (not sure if I can call you that, given the age gap :rofl:). Why would a skin "not part of a suite" make an extra folder to keep required files?

It's just redundant.
User avatar
sl23
Posts: 1140
Joined: February 17th, 2011, 7:45 pm
Location: a Galaxy S7 far far away

Re: JSMeter10

Post by sl23 »

That's fine, bud ;-)

Because if 'merged' with a suite it gets mixed up with those files.
User avatar
Active Colors
Moderator
Posts: 1251
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany
Contact:

Re: JSMeter10

Post by Active Colors »

sl23 wrote: July 5th, 2021, 9:50 pm That's fine, bud ;-)

Because if 'merged' with a suite it gets mixed up with those files.
That's a rather unexpected use-case scenario. Neither separate skins are determined to be merged, nor Rainmeter is made for such purposes.

What is the purpose of merging them? 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.
User avatar
Yincognito
Rainmeter Sage
Posts: 7017
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: JSMeter10

Post by Yincognito »

sl23 wrote: July 5th, 2021, 5:50 pmSo my original 'gripe' is really a request I suppose that future skins, not part of suite, have any resources placed in subfolders:
#@#Resorces/Name_of_skin
Wait a minute, I thought you wanted that skins that are part of a suite to structure their resources in such a way that one could differentiate between which resources are used by which skin, i.e. [SuiteFolder]\@Resources\Weather\..., [SuiteFolder]\@Resources\Visualizer\..., [SuiteFolder]\@Resources\Feeds\... and so on, where Weather, Visualizer and Feeds were hypothetically individual skins (aka .ini files) of that suite. That would have some logic as someone else could easily grab any of the individual skins of that suite to build his own "suite" / "setup" made of various skins from different suite sources (e.g. jsmorley's weather skin placed near death.crafter's GPU skin and my clock skin or similar).

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. :uhuh:

The whole advantage of the @Resources folder, aside from offering an optional "default" place to store a skin or suite resources, is the fact that a skin designer can write just 3 characters to use it, i.e. #@# for its entire path. Many skin authors take advantage of that and place all their resources there (i.e. in the @Resources folder of their skin or suite), shortening up their code and making it clearer. That is, of course, problematic for a user who wants to identify a suite skin's dependencies, but causes no problem if the skin is an individual one.

Other than that, what skins (and from which suites) you actually want to "combine" into your own "suite"? Maybe creating a thread on this subject will be of some use and folks will be able to help you identify what your suite should contain to make it work? In the meantime, an (improvable) Regular Expression search pattern for Notepad++ that should identify most (file) dependencies (irrespective if they are in options or bangs) when triggered in a skin's main .ini file, maybe it will be of some help:

Code: Select all

(?i)(?<=\s)(?:@Include.*?|LocalFont.*?|ImagePath|MouseActionCursorName|ToolTipIcon|BarImage|BitmapImage|ButtonImage|PrimaryImage|SecondaryImage|BothImage|PrimaryImagePath|SecondaryImagePath|BothImagePath|ImageName|PlayerPath|ScriptFile|MeasureName|Plugin|URL)[ =].*?(?= "|\]|\R)
The last 3 patterns in the (?:non capturing group), i.e. |MeasureName|Plugin|URL are included because in some cases you can have an image path set by MeasureName, a plugin placed somewhere, or a local URL - feel free to remove any |pattern you don't need.

Note: Of course, if the above options represent some other measure in the skin, you'd still need to figure out what that measure's value will be, but at least the regex above will point to such a measure...
Last edited by Yincognito on July 5th, 2021, 10:58 pm, edited 2 times in total.
Post Reply