Kaelri wrote:Frankly, if I were to design an operating system, I'd do it like the Mac and keep every component of an app in one place. I mean, I think this is the best way to go, given Windows' paranoid desire to monopolize the information on your own computer. But I do wish the everything-in-Program-Files method had worked out.
I'm definitely interested in AutoIt's capabilities; I know I've barely scratched the surface. (I found it while Googling for a freeware installer-maker, honestly.) In the long run, I can imagine two methods of using this with the current structure of Rainmeter:
- Release every theme with two copies of every skin: the active file, and a "master" copy with variable terms. The user would enter his personal parameters in a dialog window of some kind, which would be applied to the master and saved as the active. There are two downsides to this: it would invariably double the space requirement, and if the user ran the dialog at a later time, it would overwrite any manual edits he had made to the skin - unless he edited the master, which would be a pain. Either way, the simple fact of having two copies would be sure to confuse the hell out of casual users.
- Much better method, if it's possible: have the skin include some kind of marker, indicating that the next line is the one to be edited with a new parameter.
This is all before I've even looked at how AutoIt (or any other INI editor) works, of course.
I agree that it is unfortunate that putting everything in Program Files (like the release version of Rainmeter does today) for all programs, and have the only thing stored somewhere else is data you create (like word documents) stored in "My Documents" didn't work out. It was simple and easy to manage. I imagine that they could have gone another way, with just protecting .exe and .dll files in Program Files with UAC and not protecting the entire folder. I suppose there is some good reason they went the way they did, probably having to do with the fact that there are a large and ever growing number of extensions which are either directly or indirectly "executable". Guess we have to just live with it.
I was thinking that the installer would parse the .ini file and look for entries like this that the skin maker would put in the "uninstalled" version of the skin's .ini file:
[Variables]
WeatherLocation=!RainInstall!
WeatherURL=!RainInstall!
BrowserPath=!RainInstall!
Or in a measure:
[MeasureCPU0]
Measure=Plugin
Plugin=Perfmon.dll
PerfMonObject="Processor"
PerfMonInstance=!RainInstall!
PerfMonCounter="% Processor Time"
PerfMonDifference=1
InvertMeasure=1
The installer would collect all these required inputs by parsing the .ini looking for !RainInstall!, and provide a GUI where the user would set the actual values. It would have to be a fairly clever and dynamic GUI, as there could be anywhere from 0 to xxx of these inputs the skin maker sets up in the .ini. Probably something with a scrollable list box of the entries, and when you click on one it allows you to enter the value in a input box below the list and changes the list to show the input values so the user knows which ones they have set.
I am a bit concerned about some arcane setttings like the PerfMonInstance=!RainInstall! above, as without the "context" of looking at the entire measure or meter it might require some "release notes" by the author to let people know what is expected and why in PerfMonInstance=!RainInstall!.
The nice thing about this approach is that it doesn't REQUIRE the user to use the installer. If they want to just edit the .ini and replace the !RainInstall! entries with real values and put the files where they belong that is up to them. Nothing about this method makes the skin "unusable" unless they run the installer.
Note: This is meant to support "installing" not "modifying". I am in no way interested in, nor do I think anyone would use, a full blown GUI to "modify" Rainmeter skins. So it's a one-way trip. Once it's installed all !RainInstall! entries will be replaced and any manual editing the user does after that can't be managed by "re-installing" the skin. If they want to change their "Location" or "BrowserPath" after the install, they do it by editing the skin as we do today. The installer is only ever run once, unless they want to start over from scratch.
Then the installer would replace the !RainInstall! entries with the actual values, copy the files to the correct locations based on the Windows environment variables for APPDATA and DOCUMENTS and such, edit Rainmeter.ini to insert the skin section, set Active=1 and Restart Rainmeter.
One issue which would have to be worked through is what to do about "portable" installations where you don't want to use APPDATA/DOCUMENTS etc... Might have to be a check box in the GUI to tell the installer it's portable, so it will keep everything in the current directory. Devil is in the details on that one, but it's doable.
