How To Create A Stand Alone Patch For An Existing Skins Suite?

[balala]

It can be done in a complete package. but there are advantages to patches. One advantage, to say, a weather patch in a suite versus a complete package, is the end user does not have to redo all of their personal settings; HWiNFO settings alone can take a lot of time to reset. A patch would not require resetting anything not related to the patch update.

I think this could be done either by setting the Variables files onto the Advanced tab of the Skin Packager (as jsmorley posted the link above), or maybe by checking Merge skins on the same dialog.

[jsmorley]

I think this could be done either by setting the Variables files onto the Advanced tab of the Skin Packager (as jsmorley posted the link above), or maybe by checking Merge skins on the same dialog.

Right. I think the "merge skins" functionality has some real use with a big suite you are updating. What that will do is add or replace any files you include in your .rmskin, while leaving alone any existing files on the user system that are NOT in your new .rmskin. That will allow you to just add new files or change existing files, while not replacing any files you are not changing, nor importantly, replacing .inc files that may contain settings that the user has set for the suite.

So in your .rmskin, only include the files you want to add or replace. This will likely take some up-front work on your part, perhaps creating a temporary config folder to hold just the files you want to include, or alternatively, "hiding" the files you don't want to replace or change. Hidden files will not be included in the .rmskin.

You can even use a combination of "Variables files" and "Merge skins" if desired.

Just be clear that this .rmskin will require that the user already have some earlier version of the suite installed.

[balala]

Hidden files will not be included in the .rmskin.

Good to know this extremely important detail. I suppose this should be mentioned on the Help page of the Skin Packager as well (I think it is not yet).

Just be clear that this .rmskin will require that the user already have some earlier version of the suite installed.

Exactly and the user have to create two different package: the installer and the patch. If he releasis only the patch, new users who didn't have the skin installed, won't be able to use it.

[jsmorley]

Good to know this extremely important detail. I suppose this should be mentioned on the Help page of the Skin Packager as well (I think it is not yet).

It is mentioned, in the "Advanced" section.

[eclectic-tech]

Just be clear that this .rmskin will require that the user already have some earlier version of the suite installed.

What you just described is a "patch" to an already existing skin.

Yes, it is possible to not touch known user settings files, but they may have made other changes to their skins that could be overwritten by the new skins. So a precise, well explained, merge would be my option when only a few changes are needed to a specific area of a suite.

As long as the end user is aware of the changes that will happen, both methods are possible.

[balala]

It is mentioned, in the "Advanced" section.

Yep, it indeed is. Missed this before.

[CodeCode]

So in your .rmskin, only include the files you want to add or replace. This will likely take some up-front work on your part, perhaps creating a temporary config folder to hold just the files you want to include, or alternatively, "hiding" the files you don't want to replace or change. Hidden files will not be included in the .rmskin.
You can even use a combination of "Variables files" and "Merge skins" if desired.
Just be clear that this .rmskin will require that the user already have some earlier version of the suite installed.

This was my initial take on how the process would work. Simply add only what has changed and leave the rest. In my case some core files which would actually be the primary include file would be being changed. But now my idea is to make a tertiary inc file that handles the updated changes, leaving the huge amount of settings a user would already have set intact, and that are part of the core design, to have settings enabling as much customisation as possible to the suite as a whole.

Which brings me to my update and the easy choice to have a tertiary inc file, which would be enabling the option to switch between several core inc files so that global changes would have more than one theme, which to start there is only one 'theme' possible, and adding the ability to have as many as needed would be part of the patch.

So my next question is this:
How can an inc file be generated with all of the available options to have settings for, be generated on demand, with say a top limit of 5 copies, for example.

Ok, I will answer that myself, and would have a core protected inc file that would be duplicated with the xcopy command in a Command Measure, and would reserve all of the options either to be duplicated in full or to be a blank inc file with all of the options unassigned.

I am tempted to make a gui of some kind but there are so many options that the gui would be really unnecessarily complex when simply using the old fashioned method of setting the variables manually makes more sense in my case.

I will start to pull these ideas together, and it is likely that more questions will arise. I will necro this thread as things go forward so that future searches will point to the process as a whole rather than piece meal several threads with slightly different questions all about the same thing: updating a large suite with existing information en'situ but further enabling wide scale changes to be made in kind.

This all stemmed from simply having a graphical update option for just appearance sake, but now I am favouring this idea to have multiple themes.

I am also going back to sharing this suite as a multimonitor suite, rather than just having many options no matter how many displays the end user might have, to be honest that kind of release got a lot more page visits and downloads. Can't hurt to try and make it more attractive to the devart stats for 'follows', or DLs, aye?

[CodeCode]

It can be done in a complete package. but there are advantages to patches. One advantage, to say, a weather patch in a suite versus a complete package, is the end user does not have to redo all of their personal settings; HWiNFO settings alone can take a lot of time to reset. A patch would not require resetting anything not related to the patch update.

So it can be done either way, it is the authors choice on how he wants to offer the changes: redo everything in a suite setup, or offer a correction to a specific item.

I really only want to add some png files that would replace pre-existing images. In fact there are only 3 png files that would need to be replaced.

Please eclectic-tech, describe the patch option. I don't want to mess up existing settings - there are literally dozens of settings that are manually set by the end user.

But only 3 png files that need be replaced.

[jsmorley]

I would right-click each file except the .png files, and using "Properties" set them all to "hidden".

Then create the .rmskin, using the "Merge skins" selection under Advanced.

That should create a .rmskin that contains just the .png files, which will be installed when run, only writing the .png file and not removing any existing files on the system.

[CodeCode]

Is setting the files to 'hidden' essentially make them 'not there at all'?

If so, then I got it.

Thanks.