D8156: Fix registration of the enabled state of plugins

[Friedrich W. H. Kossebau]

kossebau created this revision.
kossebau added a reviewer: KDevelop.
Restricted Application added a subscriber: kdevelop-devel.

REVISION 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.

REPOSITORY
  R32 KDevelop

BRANCH
  fixEstimatingDefaultEnabledPlugin

REVISION DETAIL
  https://phabricator.kde.org/D8156

AFFECTED FILES
  kdevplatform/shell/plugincontroller.cpp
  kdevplatform/shell/plugincontroller.h
  kdevplatform/shell/settings/pluginpreferences.cpp
  kdevplatform/shell/shellextension.h
  plugins/cmake/tests/test_cmakemanager.cpp
  plugins/cmake/tests/test_ctestfindsuites.cpp
  plugins/custom-buildsystem/tests/test_custombuildsystemplugin.cpp
  plugins/qmakemanager/tests/test_qmakeproject.cpp
  plugins/qmljs/duchain/tests/test_qmljsdeclarations.cpp
  plugins/qmljs/tests/test_files.cpp
  plugins/subversion/tests/test_svnimport.cpp
  plugins/subversion/tests/test_svnrecursiveadd.cpp

To: kossebau, #kdevelop
Cc: kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20171006/5e1b65bc/attachment.html>