Created attachment 108179 [details] session's project config Commit #781bb47c95fabd7e28eb2c6966deb8daeb557fb5 introduced a regression that extends a long-standing issue in the cmake and manpage doc plugins to all documentation plugins. I've reported this before here and there, I consider that the current regression justifies a new report because it should help pinpoint the underlying cause. Since that commit I can no longer get rid of the documentationview, making KDevelop unusable to me: 1) in a running KDevelop session, remove the documentation toolbar button from the toolbar (suppose the view wasn't open) 2) quit KDevelop 3) reopen the same session and notice how the documentation view is open 4) try to close the documentation view with the close button (doesn't work for me) 4b) close it using the button 4c) use the patchreview plugin (e.g. "contextmenu/git/show differences") and exit from that view 4d) notice how the documentationview has opened itself again 5) back to 1) I've lived with this poltergeist by disabling the non-crucial cmake and manpage documentation plugins. I do NOT want to have to disable the Qt help plugin too. Reverting commit #781bb47c95fabd7e28eb2c6966deb8daeb557fb5 also reverts the regression.
Created attachment 108180 [details] session's 2nd project config
Created attachment 108181 [details] sessionrc config file FWIW, I get this in all my sessions.
The venom is in this hunk, the other appears to be without negative side-effects: diff --git kdevplatform/shell/documentationcontroller.cpp kdevplatform/shell/documentationcontroller.cpp index 7b0a0c156d..bde3c96ff4 100644 --- kdevplatform/shell/documentationcontroller.cpp +++ kdevplatform/shell/documentationcontroller.cpp @@ -128,7 +128,7 @@ DocumentationController::~DocumentationController() void DocumentationController::initialize() { - if(!documentationProviders().isEmpty() && !(Core::self()->setupFlags() & Core::NoUi)) { + if (!(Core::self()->setupFlags() & Core::NoUi)) { Core::self()->uiController()->addToolView(i18n("Documentation"), m_factory); } } --
Can confirm that behaviour to some degree: on restart of KDevelop the Documentation toolview reappears despite having been removed before closing. Seems that somehow the call to Core::self()->uiController()->addToolView(..., Create) from DocumentationController results in different behaviour compared to similar calls from plugins. Having a look right now.
Yes, most other plugins don't behave that way. Two that do are the debugger plugins; they also have the habit of restoring their toolbar. In their case it's more hit-and-run, indicating that plugin initialisation order has something to do with it. Whether or not the documentation toolview actually opens is a bit random, possibly also order dependent (seems linked to CPU speed and load for me). I've been working around this issue for so long that my memory is a bit dusty as to what's going on. IIRC the core shell first restores global/session-wide settings and then the settings of individual plugins. That would mean plugin settings can leak from one session to another, which still wouldn't explain why those settings aren't rewritten by those from the current session.
Git commit 6e3cfe24215e821978e4a1bb13ba2f5681a7d3f0 by Friedrich W. H. Kossebau. Committed on 05/10/2017 at 15:08. Pushed by kossebau into branch '5.2'. Fix documentation tool view re-adding itself to dockers on restart FIXED-IN: 5.2.0 M +5 -3 kdevplatform/shell/documentationcontroller.cpp https://commits.kde.org/kdevelop/6e3cfe24215e821978e4a1bb13ba2f5681a7d3f0
Touching wood, but you seem to have resolved this. I had a hunch it had to be something very simple. I haven't tried to restore the toolview to my toolbars yet to see if the view no longer reopens itself all the time. It's great to have context-based CMake documentation again, thanks!