[Suggestion] Compiling RMSKINs in command line

[Cariboudjan]

How about being able to compile an RMSKIN with command line? It would make is easier to re-package the RMSKIN through Rainmeter if users could create batch scripts to compile all of the necessary skins, settings, and plugins required for the distributable.

Something to think about?

Right now I have three or four different versions of my skin each with different combinations of images, skins, plugins etc. I use a batch script to create three copies of the skin's folder, and make the necessary changes to each copy respectively. Then I need to compile each of the folders into an RMSKIN individually. If I could compile an RMSKIN through command line I would be able to create three fully-ready RMSKIN packages in a single click whenever I'm ready for distribution.

For example

SkinInstaller.exe -FolderName -FolderLocation -Plugin1,Plugin2,Plugin3,Plugin4 -MinimumVersion -UserVariables -HeaderImage -LaunchINI

Would also be great because I would be able auto-generate a version number for the RMSKIN through the batch file.

[jsmorley]

I'm not opposed to the concept really, but I have to say that this would be a humongous level of effort with a minimal amount of return on investment.

In any case, in our view, having the creation of .rmskin files be both manual and a bit of a pain is one thing that keeps away the bad actors that would no doubt love to automate creating a boatload of evil .rmskin packages.

[Cariboudjan]

What about an option in the SkinInstaller to import the required properties from an INI file?

Code: Select all

[rmskin]
Name=Droptop
Author=Cariboudjan / TW
Version=4.29.19
LoadType=Skin
Load=Droptop\Other\Welcome\Update.ini
VariableFiles=Droptop\@Resources\GlobalVar\UserSettings.inc | Droptop\@Resources\Symbols\Symbols11.inc | Droptop\@Resources\GlobalVar\ThemeSettings.inc | Droptop\@Resources\GlobalVar\Supporter.inc | Droptop\@Resources\GlobalVar\ToolbarSettings.inc | Droptop\@Resources\GlobalVar\TopBarPositions.inc
MinimumRainmeter=4.4.0.3408
MinimumWindows=5.1
bmpimage=C:\bmp.bmp

[plugins32]
Plugin1=C:\Plugins\32\plugin.dll
Plugin2=C:\Plugins\32\plugin.dll
Plugin3=C:\Plugins\32\plugin.dll

[plugins64]
Plugin1=C:\Plugins\64\plugin.dll
Plugin2=C:\Plugins\64\plugin.dll
Plugin3=C:\Plugins\64\plugin.dll

[death.crafter]

I agree with Carib here. If there were a config file to choose when packing a skin, it would be easier. Mostly when there are a lot of plugins. Also sometimes you miss one and break your skins

[jsmorley]

Just my take on it, but this idea of a separate config file is just not likely to happen. Sorry, but I don't think I like it. The amount of parsing and error detection and validation that would be required is just not acceptable. I wouldn't trust anyone, including myself, to consistently create what would be a lengthy config file without getting it wrong.

What we might chew on is a way to "edit" an existing .rmskin file. By that I mean something like:

1) You open the .rmskin creation dialog as usual.
2) In that, you select an existing .rmskin file.
3) It reads that file and populates all the information in the creation dialog.
4) If you are just changing skin .ini file contents and the like, you just click "Finish" or whatever, and it creates a new version of the .rmskin using the latest stuff.
5) You can also add or remove Layouts and / or Plugins and change any other dialog setting before creating it.

Seems to me that this, while still complicated, might address some of the "pain in the butt" involved in managing a rmskin that you want to update on a regular basis.

Having said that, there are gotchas and complexities with this as well, since it would depend on the .rmskin being based on an existing config folder on your system. Not sure how you protect from having someone download a .rmskin and try to "edit" it for some unknown reason. Don't forget that today, the creation dialog doesn't "take your word" for anything. You have actually find and "choose" all the skin, layout, plugin files, so there is no way lie to it.

Most importantly, the rmskin doesn't store the "location" of where skins, plugins, and layouts are on the system the .rmskin was created on, but just stores the actual files. So it would be a challenge to be able to walk that back to the original source. It would almost certainly require significant changes to how the .rmskin stores things, since it would need to not only store the files, but where they originally came from. This means it would never work on existing .rmskin files, only new ones.

Not committing to doing anything at all at this point, in fact, chances are we wont... This is large effort with small benefit. More just thinking out loud.

[SilverAzide]

Not committing to doing anything at all at this point, in fact, chances are we wont... This is large effort with small benefit. More just thinking out loud.

Well, I've been asking for a command-line or MSBuild type option for few years now, but I know it is not simple to do and there are certainly more important things to address for the 99% of folks who don't need this sort of feature. But that said, I like where your thoughts are going on this.

The issue I see is one you pointed out, that the source of the files is not retained anywhere. Some extra keys in the RMSKIN.INI might address this, but that would leak some personal information (if anyone cares). What if the skin packager, at the conclusion of creating an .rmskin, spit out some sort of log/ini that kept this info, which then could be re-read the next time to gather the source paths? In other words, you'd point the packager at an existing .rmskin, it would open the file to read the contents, and (try to) open a matching .whatever file (if it exists) to get the paths to the sources.

[death.crafter]

Okay, that's a straight no. I don't mind but I have seen people hiding their username and stuff. So it's a bad idea to store local info.

But a plugin folder option would be good. We can just put necessary plugin in one folder and select that. Rainmeter can get all the child items from that folder and stuff. If somethings missing you get an error like you do. And 32 bit inclusion should be made optional.

[Cariboudjan]

Is there anything we could do as a community to take this into our own hands then?

Is it possible to build a third-party RMSKIN installer/packager...

Give me the source files I'll do it myself.

And as a side note, anything that benefits the authors DOES benefit the end users as well. We're the ones actually making the damn stuff. Why shouldn't we have the tools to build stuff? If I could compile an RMSKIN through terminal I could create the copies, edit them, compile the rmskin, commit and publish the content to github with a single script. Man that would be awesome, wouldn't it?

It would be so painless I could have daily updates. Right now it's just such a pain to compile the RMSKIN(s) that I barely make the effort, especially since I probably need to repeat that process multiple times for each copy because there is always some post-compilation error that needs to be fixed.

[SilverAzide]

Is there anything we could do as a community to take this into our own hands then?

Is it possible to build a third-party RMSKIN installer/packager...

Give me the source files I'll do it myself.

You know Rainmeter is open source, right? Everything you need is on GitHub. Make the changes and submit a pull request and maybe it will get accepted. Wouldn't be the first time someone has made a contribution this way...

[jsmorley]

Is there anything we could do as a community to take this into our own hands then?

Is it possible to build a third-party RMSKIN installer/packager...

Give me the source files I'll do it myself.

And as a side note, anything that benefits the authors DOES benefit the end users as well. We're the ones actually making the damn stuff. Why shouldn't we have the tools to build stuff? If I could compile an RMSKIN through terminal I could create the copies, edit them, compile the rmskin, commit and publish the content to github with a single script. Man that would be awesome, wouldn't it?

It would be so painless I could have daily updates. Right now it's just such a pain to compile the RMSKIN(s) that I barely make the effort, especially since I probably need to repeat that process multiple times for each copy because there is always some post-compilation error that needs to be fixed.

Absolutely. A separate 3rd-party tool for this might be just the ticket. Just be sure to follow the approach we use to add the security features to the .rmskin, or Rainmeter won't install them.