Skin Packager improvement

[balala]

A few days ago I posted a question, but got no reply at all, not even now. So I suppose there is no solution. My question was related to a file, which stores variables, which don't exist when the skin is installed, but later they are created over use.
So, here are a few deatils: I include into a skin installer package a file, which is empty at the beginning, having only a [Variables] section name, but no variables. Then after the skin is installed and get starting using, variables are created regularly and written to this file (for instance one new variable each day). Over time, more and more such variables are added into this file.
If I update the skin, wrting a new version, obviously I'd like to create a new installer. But I'd like to make it in way to keep the already added variables. Problem is that if I add the file to the Variables files field (available on the Advanced tab of the Skin Packager) when installing the new version of the skin, I get the file empty (as it is in the installer package), not with the already existing variables. I suppose the file would keep only those variables which would exist into both, the installed file and the file included into the installer (but having different values).
Is it possible to achieve this and if it's not, is there an intention to add such a feature to skin packager?
Thanks.

[Yincognito]

A few days ago I posted a question, but got no reply at all, not even now. So I suppose there is no solution.

I feel you - sometimes there isn't anyone that can help the helper. But, as I always say, there is always a solution - you just have to really want to find it, that's all.

Now, regarding the question, jsmorley or SilverAzide might be the ones that know more about the Variables files field (available on the Advanced tab of the Skin Packager) or the Merge (I think) option there, but I propose a different approach. Since your variables file is more or less empty at the start and you just want it - and its content - to "persist" across overall skin "upgrades", why not getting rid of including it in the skin package altogether, and instead create the file on your skin's first run, from your skin?

For example, both:

Code: Select all

>>"Variables.inc" type nul

and

Code: Select all

IF not EXIST "Variables.inc" type nul>"Variables.inc"

create an empty Variables.inc file in the current folder (if you want to create it some place else you'd have to use a specific - maybe even a relative - path, obviously) if the file doesn't yet exist, and do nothing (in other words, preserve the file and its content) if the file already exists.

Naturally, one of these commands can easily be included in a (visually hidden) RunCommand measure in your skin, which will be executed on each skin refresh (either by using OnRefreshAction in the [Rainmeter] section or simply having an UpdateDivider=-1 measure command it to run). In practice, this would only create the file on the skin's first run, since if the file exists nothing happens, even though the RunCommand measure itself is commanded to run on each skin refresh, so as far as I can tell, it achieves the goal.

P.S. I'm pretty sure some slight modifications can be performed on either of the above commands if you want the file to have the [Variables] line written in the file on creation, but then, this isn't really needed, as the WriteKeyValue bang (which you probably use to write variables in the file) writes the section name (i.e. [Variables]) into the file anyway, if it's not there already. You can of course write these commands in a batch (.BAT) file as well (some slight syntax modification might be needed though) if you want to make the process more complex, but for what you mentioned above, this should be enough.

Hopefully I understood your question properly and this helps you to achieve what you want. If not, let me know.

[balala]

Sorry for the extremely late reply, but today had a more or less full day, with other things I had to work with around.

I feel you - sometimes there isn't anyone that can help the helper. But, as I always say, there is always a solution - you just have to really want to find it, that's all.

Now, regarding the question, jsmorley or SilverAzide might be the ones that know more about the Variables files field (available on the Advanced tab of the Skin Packager) or the Merge (I think) option there, but I propose a different approach. Since your variables file is more or less empty at the start and you just want it - and its content - to "persist" across overall skin "upgrades", why not getting rid of including it in the skin package altogether, and instead create the file on your skin's first run, from your skin?

For example, both:

Code: Select all

>>"Variables.inc" type nul

and

Code: Select all

IF not EXIST "Variables.inc" type nul>"Variables.inc"

create an empty Variables.inc file in the current folder (if you want to create it some place else you'd have to use a specific - maybe even a relative - path, obviously) if the file doesn't yet exist, and do nothing (in other words, preserve the file and its content) if the file already exists.

Naturally, one of these commands can easily be included in a (visually hidden) RunCommand measure in your skin, which will be executed on each skin refresh (either by using OnRefreshAction in the [Rainmeter] section or simply having an UpdateDivider=-1 measure command it to run). In practice, this would only create the file on the skin's first run, since if the file exists nothing happens, even though the RunCommand measure itself is commanded to run on each skin refresh, so as far as I can tell, it achieves the goal.

Interesting approach, have to take it into account. Tomorrow I'm gonna take acloser look to see if everything is alright, but I hope it is. Thanks for the (hope very good) idea.

P.S. I'm pretty sure some slight modifications can be performed on either of the above commands if you want the file to have the [Variables] line written in the file on creation, but then, this isn't really needed, as the WriteKeyValue bang (which you probably use to write variables in the file) writes the section name (i.e. [Variables]) into the file anyway, if it's not there already.

Well, this is something I had no idea at all about. But after a quick try, it definitely does work, so thanks again.
As said, today not, but tommorow I'll study this approach, to see if it indeed is a good way to achieve what I need.

THANK YOU VERY MUCH for the idea. Hope it's gonna work. I'll let you know if it indeed does, once I tried it out.

[Yincognito]

Sorry for the extremely late reply, but today had a more or less full day, with other things I had to work with around.


Interesting approach, have to take it into account. Tomorrow I'm gonna take acloser look to see if everything is alright, but I hope it is. Thanks for the (hope very good) idea.

Well, this is something I had no idea at all about. But after a quick try, it definitely does work, so thanks again.
As said, today not, but tommorow I'll study this approach, to see if it indeed is a good way to achieve what I need.

THANK YOU VERY MUCH for the idea. Hope it's gonna work. I'll let you know if it indeed does, once I tried it out.

Good luck with the attempt tomorrow (or whenever you are able to) - looking forward to see how it goes in your actual environment. The CMD part I tested worked fine, so IMHO it's just a matter of whether I understood what you wanted to do properly or not.

[Active Colors]

I would use the backup feature when updating a skin.

When you update a skin the previous version of it is backuped.
After it is updated I would make my skin run a command on the first run which will import necessary variable values from backuped skin.

[balala]

I would use the backup feature when updating a skin.

When you update a skin the previous version of it is backuped.
After it is updated I would make my skin run a command on the first run which will import necessary variable values from backuped skin.

Another idea which definitely has to be taken into account. Thanks for it. Now I have enough time and will try to choose one of the solutions.
Thanks both once again.

[Yincognito]

I would use the backup feature when updating a skin.

When you update a skin the previous version of it is backuped.
After it is updated I would make my skin run a command on the first run which will import necessary variable values from backuped skin.

Just curious, when you say "import", what do you mean by it? Copying the contents of the backed-up file to the new file, reading it with WebParser, @Include it, or some other technique I'm not aware of?

Since we're at it, this is a good idea, cause I'm thinking one doesn't even need a command to run on the first skin activation - it can be done much easier (not that the already available soutions are complicated, of course), by simply @Including both the "new" (presumably, empty) variables file AND the "old" (i.e. backed-up) variables file in the skin ... but in this order, so that the backed-up variable values would overwrite the possible values in the new file. Like:

Code: Select all

[Variables]
@IncludeVariables=#@#Variables.inc
@IncludeBackedUpVariables=#SKINSPATH#@Backup\#ROOTCONFIG#\@Resources\Variables.inc

Obviously, #ROOTCONFIG#\@Resources can be replaced by, say, #CURRENTCONFIG#\@Resources, or whatever your actual relative path to the variables file is. So, in the above code, the "old" variables file's values would overwrite similar values from the "new" variables file since the former's inclusion comes after the latter's one, in effect preserving old existing variable values. Unless there is some same section name conflict (since all section names must be unique in the INI format, and I didn't test the approach to see if it works) that would prevent this from happening, this could be enough...

P.S. I'm not sure whether the backed-up file's inclusion would fail silently if that file doesn't exist or would generate a Log error, but in any case, I believe this wouldn't prevent the functionality. The only question is regarding same section name, but even that can probably be easily avoided.

[balala]

The CMD part I tested worked fine, so IMHO it's just a matter of whether I understood what you wanted to do properly or not.

Yep, you did understand it well and I'm studying your solution right now (will study Active Colors's solution a little bit later). It might be affordable, however I have one difficulty which I failed to get over. If I create the file either with a RunCommand plugin measure, or with a lua script, I get the file with UTF-8 encoding, but it should be a UTF-16 LE, as known. Does anyone know a way to either convert the encoding of the just created file, or from the beginning to create it with the proper encoding?
Thanks for any kind of help.

[Yincognito]

Yep, you did understand it well and I'm studying your solution right now (will study Active Colors's solution a little bit later). It might be affordable, however I have one difficulty which I failed to get over. If I create the file either with a RunCommand plugin measure, or with a lua script, I get the file with UTF-8 encoding, but it should be a UTF-16 LE, as known. Does anyone know a way to either convert the encoding of the just created file, or from the beginning to create it with the proper encoding?
Thanks for any kind of help.

Will investigate it and let you know.
In the meantime, I just tested the approach in my last reply (based on ActiveColors' idea), and it works. Non-existing included files do not fail silently and there is, of course, the possibility that the user accidentally or intentionally deleting the backed-up files from the @Backup folder, but then, these are only minor issues:

Test_1.0.0.rmskin

Test_1.0.1.rmskin

These are two basic versions of the same skin, which displays the existing variables. It's up to you to see if it does what it should. From my point of view, it does.

[balala]

Will investigate it and let you know.

Many thanks once again. Would be great if you could find a solution, because I couldn't.

In the meantime, I just tested the approach in my last reply (based on ActiveColors' idea), and it works. Non-existing included files do not fail silently and there is, of course, the possibility that the user accidentally or intentionally deleting the backed-up files from the @Backup folder, but then, these are only minor issues:
Test_1.0.0.rmskin
Test_1.0.1.rmskin
These are two basic versions of the same skin, which displays the existing variables. It's up to you to see if it does what it should. From my point of view, it does.

To be honest as far as I can tell your example doesn't exactly fits my needs. I should have an empty .inc file included into the skin installer and when installing the skin the file shouldn't overwrite the existing similar file, because this last one includes the variables which have been created after the skin has been installed. If the skin is installed for the first time, the included file doesn't exist yet, that's why ther installer has to include the empty file.
I suppose in your example I should install first the Test_1.0.0.rmskin package and when I get it running I should install over it the Test_1.0.1.rmskin package. Is this correct? If it is, as said, it's not exactly what I want, because the included Variables.inc overwrites the existing one. My need would be to get the file copied (installed) empty when the skin is installed for the first time, but never get it overwritten when a later package (update / upgrade of the existing skin) is installed over the existing package.