<table><tr><td style="">kossebau created this revision.<br />kossebau added a reviewer: KDevelop.<br />Restricted Application added a subscriber: kdevelop-devel.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D8156" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>The old code was slightly broken:<br />
At start-up plugin controller updated the config storage only for the<br />
enabled state of the global-category plugins (and indirectly their<br />
dependency plugins). Project-category plugins would only get an update<br />
indirectly once loadProjectPlugins() was run, other plugins only once<br />
the were requested by their interface.<br />
Thus in a new session with no project yet loaded the config storage would<br />
not yet cover the enabled state of the project-category plugins and those<br />
other.</p>

<p>PluginPreferences code queried the initial enabled state of each plugin<br />
from the plugin controller, which then has extra code in the isEnabled()<br />
method to deal with that. Though that information is dropped and replaced<br />
with the one fetched from the config storage, multiple times even:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">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</li>
<li class="remarkup-list-item">selector->load() was called after plugins were added, which results in the same update from the config storage data</li>
<li class="remarkup-list-item">the PluginPreferences instance like each KDevelop::ConfigPage gets an initial call of the reset() method on setup, which again calls selector->load()</li>
</ul>

<p>Which results in the plugin selector showing wrong enabled state at least<br />
for new sessions, where no project has been loaded yet and not all plugins<br />
at least been tried to load once.<br />
While the first two times of data drop could be fixed, the third would be<br />
more complicted to do.</p>

<p>So instead of keeping the current on-the-fly enabled state calculation for<br />
non-global-category plugins, on start-up the config storage is updated for<br />
any known plugin (and then consecutively updated if failing to load a<br />
plugin when needed). This gives the plugin selector and any other code<br />
consistent data and simplifies things.</p>

<p>Next to this, this patch also restores ShellExtension::defaultPlugins()<br />
power to control which plugins should be loaded by default. Thus any<br />
tests which (try to) make use of the AutoTestShell::init plugin list<br />
feature can (and have to) now explicitly define all userselectable plugins<br />
which should be used (thus also using the correct plugin id :) ).</p></div></div><br /><div><strong>TEST PLAN</strong><div><p>Create a new session, open directly the plugin selection settings and see<br />
that all build and projectmanager plugins but also the QML plugin are shown<br />
as enabled, as they should be.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>BRANCH</strong><div><div>fixEstimatingDefaultEnabledPlugin</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D8156" rel="noreferrer">https://phabricator.kde.org/D8156</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>kdevplatform/shell/plugincontroller.cpp<br />
kdevplatform/shell/plugincontroller.h<br />
kdevplatform/shell/settings/pluginpreferences.cpp<br />
kdevplatform/shell/shellextension.h<br />
plugins/cmake/tests/test_cmakemanager.cpp<br />
plugins/cmake/tests/test_ctestfindsuites.cpp<br />
plugins/custom-buildsystem/tests/test_custombuildsystemplugin.cpp<br />
plugins/qmakemanager/tests/test_qmakeproject.cpp<br />
plugins/qmljs/duchain/tests/test_qmljsdeclarations.cpp<br />
plugins/qmljs/tests/test_files.cpp<br />
plugins/subversion/tests/test_svnimport.cpp<br />
plugins/subversion/tests/test_svnrecursiveadd.cpp</div></div></div><br /><div><strong>To: </strong>kossebau, KDevelop<br /><strong>Cc: </strong>kdevelop-devel<br /></div>