Taking a look at the code, I think one can not just keep that pointer/group around that long.

One could try to e.g. remember the keys with values for positions in finishRestore() and use that as overwrite in createToolView like we do there with

// try the restore config to figure out real pos
if (m_restoreConfig && m_restoreConfig->hasGroup(m_restoreGroup)) {
    KConfigGroup cg(m_restoreConfig, m_restoreGroup);
    pos = (KMultiTabBar::KMultiTabBarPosition) cg.readEntry(QStringLiteral("Kate-MDI-ToolView-%1-Position").arg(identifier), int(pos));
}

As long as the config pointer is valid, no operation showing/moving toolviews will have any effect.

In D22067#486282, @cullmann wrote:

Taking a look at the code, I think one can not just keep that pointer/group around that long.

One could try to e.g. remember the keys with values for positions in finishRestore() and use that as overwrite in createToolView like we do there with

// try the restore config to figure out real pos
if (m_restoreConfig && m_restoreConfig->hasGroup(m_restoreGroup)) {
    KConfigGroup cg(m_restoreConfig, m_restoreGroup);
    pos = (KMultiTabBar::KMultiTabBarPosition) cg.readEntry(QStringLiteral("Kate-MDI-ToolView-%1-Position").arg(identifier), int(pos));
}

As long as the config pointer is valid, no operation showing/moving toolviews will have any effect.

Yep, there must have been a good reason why those two variables were cleared at the end of finishRestore(); I should have looked closer for that reason; I'll rework the diff. (Sorry about the noise).

Looking closer at this, it's more complicated than I initially thought :)

The location inside a sidebar, persistence and visibility settings of a tool view are only read from the config in Sidebar::restoreSession(); so at best with the create-toolview-on-demand nature of the projects plugin, we can only set the saved position setting. I'd say that's OK, because this diff here is more about the anonymous session, which is a special case.

If the user has a named-saved session, most of the time if he has files from a git/svn/hg repo open, he's probably not going to close them before saving the session or quitting kate.

So, just restoring the position setting would be OK?

Incidentally, why is the projects plugin has its tool views created on demand? that point doesn't seem to be documented (hint: you should document it :)).

In D22067#486989, @ahmadsamir wrote:

Looking closer at this, it's more complicated than I initially thought :)

The location inside a sidebar, persistence and visibility settings of a tool view are only read from the config in Sidebar::restoreSession(); so at best with the create-toolview-on-demand nature of the projects plugin, we can only set the saved position setting. I'd say that's OK, because this diff here is more about the anonymous session, which is a special case.

If the user has a named-saved session, most of the time if he has files from a git/svn/hg repo open, he's probably not going to close them before saving the session or quitting kate.

So, just restoring the position setting would be OK?

Incidentally, why is the projects plugin has its tool views created on demand? that point doesn't seem to be documented (hint: you should document it :)).

Scratch all of the above...

OK. Here's where I am at the moment. If we store the position of the project and projectinfo plugin (one plugin, two tool views), if the user opens another session in the same window, things start getting messy as now there will be the position of the first session and the second session, so now we'd have to store the session name along with the position... this is starting to become too complicated for such a small issue.

I think this needs some more thoughts.
One could save all stored positions/... during session restore and use them on tool view creation if set.
But this is a much larger change.