For some time there has been a request for a way of creating installers for foobar config files and the files they require.

I'm proud to announce the first version of just such a toolkit. It does requires a bit of effort on the part of the config author to use, though. It uses NSIS to create an installer for distributing those parts that are allowed be distributed, and automatically downloading and installing components that are not.

Download v0.0.4 here.

It would be useful to know which components can be redistributed by bundling in an installer of this sort, and which can not. To that end, I would ask anyone with definitive information (such as the author) for a component, to add a post to this thread so that we can all know. I've started it off with one of mine further down the thread.

Update: v0.0.4
* Added built in support for Playlist Tree (*.pts) and foo_ui_panels (PanelsUI/*.*) config files
Update: v0.0.3
* Added support for 7z and rar files
* Added support for multiple components installed from the same archive without downloading it multiple times
* Switched from inetc plugin to inetload plugin, as upload capability was not required.
Update: v0.0.2
* Fixes a bug where the config file might not be backed up under certain circumstances.

is this allowed?

Hey,i've been doing the same thing today (mine is MSI based however),already got it to download components
and to extract the dll's into components folder+later remove the useless archives.
However,i was forced to include some free archiver utility within my installer,in order to deal with downloaded archives,and i'm not so happy about it.So my question is:how do you deal with that issue,or is there a components resource that provides "naked" dll's?

Wow !
I was trying to make a workaround using an sfx archive and a dos batchfile, but your stuff is much more powerful.
Great work Alex, you rock !

Well, as long as you only include material (mostly components, fonts, and images) that you are allowed to distribute with such an installer, I think it is okay. However, as far as I understand the NSIS script, it will check for required components, but not check the version, and it does not seem to have an uninstall feature that can restore your old configuration (correct me if I'm wrong), so I'd say use it at your own risk.

Hello,

Thanks for your comments, everyone. First, to answer Russel777's question, component dll's are extracted from zip files using the nsisUnz plugin to NSIS. Unfortunately it is not capable of reading files in 7z format, so for the moment components distributed in 7z archives cannot be remotely installed. Hopefully a plugin to extract from 7z files will become available sometime, and then it can be used. Until then, the only options are to request a zip format download link from the component author, or permission to redistribute the component bundled in the installer.

To address foosion's points, it's true, there is no automatic uninstaller. This is because there is no safe way to uninstall a configuration file; if the uninstaller simply rolls back to your old configuration file then you will irretrievably lose any changes you have made since then, which may include settings unrelated to the visual appearance that you might not expect to lose. A backup of the configuration file with a date and time stamp is created at install time, so if you do want to roll back, you can do so manually.

As for component version numbers, the way it works is that if you already have a component installed, it will not overwrite it. If you have a newer version of the component already installed, then this is fine, as newer versions of components should generally read older version's settings out of configuration files, as a standard upgrade path.

If you have an older version of the component installed, then it will still not overwrite it. Keeping your components up to date is still your own responsibility. I agree that a tool for automating component updates would be very cool, but is not part of the scope of this project.

So yes, use at your own risk though, like all software.

Component Redistribution Permission Status

foo_cmd_playlist: Freely available to redistribute (ref: author)

Link is ze broken.

Grr. Damn redirects. Link is now fixed.

I was thinking of making something similar both I don't have the time

My idea was this in case anyone else wants to do it:

Make a foobar2000 plugin that imports/exports/manages configurations.

If you click export then it creates a zip with the foobar2000.cfg, images directory and a list of dependencies (just a list in text, not the components themselves).

If you click import then it saves the file in a directory like configurations/ or something. This will be a dir in the foobar2000 dir. This new config will appear in the Available Configs List. It will have metadata such as name, author, URL, version etc.

Now from the Available Configs List, you can click on any config and 'apply' it. Firstly it will check that dependencies are available. If not then it should open up the appropriate website in ur browser so u can download wot u need. If all deps are met then it removes (should backup first) all current config files (except foobar2000.cfg cos it's required and it will be overwritten anyway), then it should copy all files of the new config and tell the user to restart. That way people can download all the AWESOME skins ppl on this forum have made and just change between them easily and anytime.

From the very beginning I was gonna have version numbers and URL as part of the metadata so that eventually I could add an auto-update mechanism.

Man, I'd seriously love to make this but I don't think I ever will. Takes 2 much time to create, keep up-to-date and also support. Maybe someone else likes this idea or at least would like to build on it and has the time to create it. Hopefully

I don't think it is possible to automatically determine all the dependencies of a config, given that the filenames of images can be constructed from tagz expressions. There is also no way of detecting which of the loaded components are integral to the configuration, and which are not part of it.


This won't work. Foobar overwrites the config file as it exits.


No auto update mechanism is going to get off the ground without a standardised component distribution mechanism that includes such details as version numbers. Without that there is no reliable way of finding out whether a newer version is available, or even if the version available is newer or not.

A lot of the functionality you want can be had by simply keeping a folder full of config file installers built with this toolkit, then just running whichever one you want to switch to a different config. This would, of course, rely on config authors producing them, but as I've said - there is manual work involved in specifying all the dependencies of a config

Update: v0.0.3

This version adds optional support for 7z and rar compressed component files by bundling 7za.exe and/or unrar.exe with the installer. This is allowed by their licenses.

Also added is support for multiple components installed from the same archive, without downloading it multiple times.

Finally, I've switched from the inetc NSIS plugin to the inetload plugin, as inetc was just inetload with additional functionality for uploading, which was not used here.

Download

Great,thanx a bunch! But i want to point your attention to another issue:thanks to you we now have a tools
for distributing foobar configs and download the needed components,but it turns out to be useless,b/c we don't
have functional central components repository to download the components from.I mean there is such
a repository (even two of them AFAIK),but some major components there (like single column and trackinfo mod
panel) are seriously outdated (august versions i believe).Now you can always put a link to the authors resource
inside your installer,but as soon as the author updates his component,bang!The link is not valid.So i think of
deleting the link to my installer/downloader,b/c even 3 days after it's release it's not able to download some
updated components,and it's obvious that i cannot track all the changes and update my installer every couple
of days.I hope there will be a solution.

I've tried to use http://pelit.koillismaa.fi/plugins redirection urls wherever available in the template RequiredComponents.nsh included in the toolkit. This means that if the download url in the repository is kept up to date, the installer does not need to be.

I don't think that we need (another) central components repository, all we need is for that one to be used for more components, and kept up to date if the URL changes. Perhaps it could be a bit stricter about requiring a direct download link too, rather than just a link to download page or forum thread: that would help.

This whole issue is interesting to me, as well. To me, it would seem like the obvious time for a configuration change (and similarly, a component update) would be before foobar2000 runs. This would make it perfect for foo_loader to do. I'm re-installing Delphi as we speak to see how feasible this is, but I've got an idea for a quick way to make it work.

My idea is to have "packs" of foobar configs. A "pack" is simply a compressed file (.zip, .rar, .7z? We'd need to decide), located at a certain location, that gets unpacked in the foobar2000 folder at runtime. Before a new pack is unloaded, the old pack is rearchived and saved, so it should be trivial (at the cost of a bit of a delay) to seamlessly switch configs between foobar loads.

Keeping components updated, then, is as trivial as having someone put together a pack with all new components and keep it hosted at the same location. That places the burden of component updates on a single person, but makes it very possible to distinguish trusted content from untrusted content. Moreover, anyone can do it, and it wouldn't be very difficult to make pack creation simple. Indeed, it would be smart for foo_loader to pack old configs and databases for backup anyhow.

What do you guys think?

Ahahaha, no. No chance. Given that we can't even maintain an up to date centralised list of components and URL's, I don't hold out any hope for this whatsoever.

The other small problem with continually switching configs like you suggest is the loss of any settings you change yourself, but perhaps this might not be of concern to some.

I was thinking this utility would represent a before/after in foobar2000 history, as it makes full configurated foobar accesible and easy for everyone. I tried some (Rusell one's) configurations in wich the installer was applied and it made so quick and easy to get a hi-geek Foobar for the complete idiot user.

Unfortunately, it seems that nobody is using this installer utility to make their configurations available to poor people.

Maybe there is kind of elite mentality behind expert foobar users? No general people allowed?

Uh?

Rozzo

No,it's just that it takes much more time (and effort) to pull a decent installer than to just release a config,
you can not blame other's for not doing so,since the fact that they do contribute their configs is already a huge step forward comparing to how it was b4,anyway i've already mentioned it a couple of times that i'm willing to guide those who want to make an installer using MSI technology and AlexVallat's kit comes with instructions inside already,so it's just a question of will.

Update: v0.0.4

This version adds support for the additional configuration files produced by Playlist Tree and foo_ui_panels.

Rather than use the standard .cfg file to store their settings, Playlist tree produces .pts files, and foo_ui_panels produces a PanelsUI folder with additional configuration files in it.

These additional configuration files are now automatically handled by the installer toolkit in the same way that it handles the foobar2000.cfg file, installing them to the correct location for both normal and per-user settings foobar installations, and backing up the existing config files before replacing them.

Download