In my case, I always hit the else case in the following code.

mainwindow.cpp, line 310:

    if (cg.hasKey("State")) {
        QByteArray state;
        state = cg.readEntry("State", state);
        state = QByteArray::fromBase64(state);
        // One day will need to load the version number, but for now, assume 0
        restoreState(state);
    } else {
        // If there's no state we use a default size of 870x650
        // Resize only when showing "code" area. If we do that for other areas,
        // then we'll hit bug https://bugs.kde.org/show_bug.cgi?id=207990
        // TODO: adymo: this is more like a hack, we need a proper first-start initialization
        if (area() && area()->objectName() == QLatin1String("code"))
            resize(870,650);
    }

For me it is not clear why this happens. If I remove the else case, it works for me.

I am working on this and related bugs for a while now, but get distracted with other issues. Hopefully will create a merge request next month.

(In reply to Igor Kushnir from comment #2)
> I am working on this and related bugs for a while now, but get distracted
> with other issues. Hopefully will create a merge request next month.

Thanks for your effort. Let me know if I could help with testing a patch.

A possibly relevant merge request was started @ https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/715

Git commit f424cfd87e27ed4fa33f784daf4b25c4d1660519 by Igor Kushnir.
Committed on 10/02/2025 at 14:30.
Pushed by igorkushnir into branch 'master'.

Eliminate a fork of KXmlGui's applyMainWindowSettings()

Auto-saving main window settings is enabled thanks to the Save flag
passed to KXmlGuiWindow::setupGUI(). But
KMainWindow::autoSaveConfigGroup() returns KConfigGroup(), because
KDevelop never calls KMainWindow::setAutoSaveSettings(). Thus despite
the use of area-specific config groups in
Sublime::MainWindow::saveSettings() and
Sublime::MainWindow::loadSettings(), the KXmlGuiWindow::setupGUI() call
in KDevelop::MainWindow::initialize() applies main window settings from
and sets up auto-saving to the group "MainWindow".

Since
https://commits.kde.org/kxmlgui/4eb7098a7b7b878b328b76c58d37607e75073d60
KMainWindow::saveMainWindowSettings() and
KMainWindow::applyMainWindowSettings() save/restore window size,
position and state to/from the state config instead of the
`KConfigGroup &_cg` argument. So MainWindow::loadSettings() fails to
load these settings from an area-specific config group. Depending on the
existence of the old KF5 State config, MainWindow::loadSettings()
applies either that stale and no longer updated configuration or the
default values.

In practice, this broken in several ways saving and loading causes wrong
main window size, position and tool view visibility on KDevelop start
and when the current area changes.

Call KXmlGuiWindow::applyMainWindowSettings() from
MainWindow::loadSettings() instead of maintaining a brittle fork of it.
Main window size and position restoration, which the fork had prevented,
works now, but requires code adjustments and workarounds:
1. Early-return from MainWindow::loadSettings() to postpone the special
   first call to applyMainWindowSettings() until after the UI is
   initialized.
2. Pass the default KDevelop main window size to
   KXmlGuiWindow::setupGUI().
3. Disable the auto-saving of main window settings rather than
   complicate the code significantly to make it work correctly.

Hide an IdealDockWidget before removing it to make saving and restoring
of dock widget visibility work correctly.

80436f2a717d21968366a41dbf910ec04dfbb94e introduced the fork removed in
this commit not only to work around a window size bug, but also to
prevent each save/restore cycle from moving the second toolbar to the
left. I cannot reproduce this other bug, and so assume it has been fixed
in KXmlGui by now.

a35de90ce596a7859c99c04bf62e1a7e09914bbc reused the fork removed in this
commit to prevent restoring the enabled state of the status bar. The
status bar disappearance is impossible with the current KMainWindow
implementation, because the internal-linkage function
internalStatusBar(), called by KMainWindow::saveMainWindowSettings() and
by KMainWindow::applyMainWindowSettings(), always returns nullptr in the
case of KDevelop's main window, and so these two KMainWindow functions
neither write nor read the "StatusBar" config entry. The reason
internalStatusBar() returns nullptr is that it looks for a direct
QStatusBar child of the main window (non-recursively), and
KDevelop::MainWindowPrivate::setupStatusBar() always reparents the
StatusBar immediately after its creation by adding it to the layout of
another widget. The fork's status bar code, which had caused the bug and
was removed in a35de90ce596a7859c99c04bf62e1a7e09914bbc, had diverged
from the KXmlGui implementation. The removed code looked for a
QStatusBar child of the main window recursively, found the indirect
StatusBar descendant, and hid it in case ~/.config/kdeveloprc contained
a StatusBar="Disabled" config entry for some reason.
FIXED-IN: 6.2.250400

M  +24   -1    kdevplatform/shell/mainwindow.cpp
M  +6    -0    kdevplatform/shell/mainwindow_p.cpp
M  +6    -0    kdevplatform/shell/mainwindow_p.h
M  +4    -0    kdevplatform/sublime/idealcontroller.cpp
M  +3    -56   kdevplatform/sublime/mainwindow.cpp

https://invent.kde.org/kdevelop/kdevelop/-/commit/f424cfd87e27ed4fa33f784daf4b25c4d1660519

*** Bug 501299 has been marked as a duplicate of this bug. ***