Fix registration of the enabled state of plugins
Summary:
The old code was slightly broken:
At start-up plugin controller updated the config storage only for the
enabled state of the global-category plugins (and indirectly their
dependency plugins). Project-category plugins would only get an update
indirectly once loadProjectPlugins() was run, other plugins only once
the were requested by their interface.
Thus in a new session with no project yet loaded the config storage would
not yet cover the enabled state of the project-category plugins and those
other.
PluginPreferences code queried the initial enabled state of each plugin
from the plugin controller, which then has extra code in the isEnabled()
method to deal with that. Though that information is dropped and replaced
with the one fetched from the config storage, multiple times even:
- the plugins are added to the selector using the flag KPluginSelector::ReadConfigFile, which results in the data manually set to each KPluginInfo instance with kpi.setPluginEnabled(...) being overwritten with the config storage data
- selector->load() was called after plugins were added, which results in the same update from the config storage data
- the PluginPreferences instance like each KDevelop::ConfigPage gets an initial call of the reset() method on setup, which again calls selector->load()
Which results in the plugin selector showing wrong enabled state at least
for new sessions, where no project has been loaded yet and not all plugins
at least been tried to load once.
While the first two times of data drop could be fixed, the third would be
more complicted to do.
So instead of keeping the current on-the-fly enabled state calculation for
non-global-category plugins, on start-up the config storage is updated for
any known plugin (and then consecutively updated if failing to load a
plugin when needed). This gives the plugin selector and any other code
consistent data and simplifies things.
Next to this, this patch also restores ShellExtension::defaultPlugins()
power to control which plugins should be loaded by default. Thus any
tests which (try to) make use of the AutoTestShell::init plugin list
feature can (and have to) now explicitly define all userselectable plugins
which should be used (thus also using the correct plugin id :) ).
Test Plan:
Create a new session, open directly the plugin selection settings and see
that all build and projectmanager plugins but also the QML plugin are shown
as enabled, as they should be.
Reviewers: KDevelop, mwolff
Reviewed By: KDevelop, mwolff
Subscribers: mwolff, kdevelop-devel
Differential Revision: https://phabricator.kde.org/D8156