We previously had both 'modules' and 'plug-ins' and the files are called things like mod-script-pipe.dll. Three different things. From a user's point of view it is easier to think of them as modifications to the basic program, like mods in Minecraft. Hence the name change. The search path now has 'mods' in it rather than 'modules'. Didn't see a need to rename the 'Modules' source code as programmers know what modules are and the mods are modules too.
This ensures that the config file remembers a 'fail to load'. We set status to fail before loading a module, that now gets written out to the config file because we flush prefs, the dodgy module loads and crashes, and next time Audacity knows it's a fail. If instead the module loads and does not crash on load, the original status (enabled or ask) is written back to the config file.
Previously MultiDialog attempted to centre on parent dialog, but there was a NULL parent. Now the application top window is used. Dialog shows centred, for example when there are missing block files. If the top window is a WX_STAY_ON_TOP, we move our dialog to the left, as otherwise it would be partially hidden.
Previously Audacity would ask about enabling a module whilst the splash screen was showing. For some as yet undetermined reason the MultiDialog and Splash Screen are incompatible. Possibly it's related to doing a ShowModal before a full application exists. The not ideal workaround is to now delay showing the splash screen until after the modules have been loaded.
We can't go to 3.0.1 yet as there are still build issues on
Linux and OSX. You can get Windows to build, but there's
still some display issues.
These changes should work with wxWidgets 2.8.12 as well, so
we can take our time to get things working properly before
switching over.
We do not now prompt about new modules at start up, unless you set a module to 'ask'. This means we can ship experimental modules with Audacity. Users can enable them if they want to, but aren't troubled by them otherwise.
Saves view type
Defaults to fully expanded upon entry
Live search...may need to adjust the timer
Uses black on white for the icon (should? fix assertion on Linux hopefully)
(will do more a bit later)
Anything to do with modules and prefs is currently under EXPERIMENTAL_MODULE_PREFS and turned off.
We never load 'out of date' modules (but do allow modules to interrogate the current prefs and 'pretend' they are that version. The 'Aurora' plug-ins do that).
If a module is 'out of date' we provide the name in a user-facing message and actual location in the log, just in case the user has a number of versions in different places (untested).
We currently don't remember the users preference for loading each module, but could extend this. We would need an extra button in the ShowMultiDialog of ModuleManager::Initialize and then store the preferences in prefs. That would need a more sophisticated entry in prefs->Modules to enable a user to change their decisions.
