Persistent configuration

[kynikos]

Let the user configure some parameters persistently.

This could be done through a configuration file, but the various browsers have different degrees of support for reading/writing local files, for security reasons.

A much more portable and safe way would be storing the configuration in a JSON cookie, and providing an interface for editing it (this could even be a simple text area that could present the attributes e.g. in YAML, though requiring a proper library would be necessary for that). The interface should also let manually import/export configuration from/to local files.

[lahwaacz]

It could be possible to use MonkeyConfig (or something similar) to manage the config files and dialogues.

[kynikos]

Uh that's a brilliant idea, but there haven't been updates for years except for a fix for Chrome, it may need forking.

[kynikos]

Probably better, use HTML5 localStorage, then let export the configuration to a file for editing however the user wants, and of course re-import it.

This could even allow maintaining only a single, "full" configuration in the repo, and let the users disable what they don't need.

[kynikos]

Configuration objects/files must keep a reference to the WM version they apply to, because the development of the application can't be limited by the need to preserve backward compatibility: it should be clear that it's not supposed to be edited, something like "DoNotEditNorRemoveThis": "h8hj437s", where the random string is unique for every WM release. For something more good-looking, "CompatibleWithWikiMonkeyVersion": "1.18.0" should be enough to understand that manually modifying it means looking for trouble. Also, a configuration update mechanism must be created that is triggered when an outdated configuration is loaded. Remind to update the mechanism in the RELEASE procedure.

[kynikos]

Once implemented, only the full-featured configuration can be released, and other configuration objects can be made available for copy-pasting/download. The installation instructions will simplify a lot of course. The deprecated versions should warn the user to install the unified version and instruct them to load the needed configuration object.

Maybe this is a big-enough change to justify a 2.0.0 release.

[kynikos]

Actually, scrap the configuration versioning and updating; each plugin will be installed dynamically instead, and its configuration loaded with it through simple key/value objects. For the grid interface, each plugin can add itself to a group; null group means install it by itself; see also #196.

Also implement importing/exporting from/to a file for convenience over copy-pasting.

[kynikos]

In the configuration interface, display WM version and a list of the installed plugins.

[kynikos]

Implemented, but in an even more different way :P