https://bugs.kde.org/show_bug.cgi?id=381310

Igor Kushnir <igor...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Version Fixed In|                            |6.2.250400
             Status|ASSIGNED                    |RESOLVED
      Latest Commit|                            |https://invent.kde.org/kdev
                   |                            |elop/kdevelop/-/commit/b76e
                   |                            |7a27aa2db2b0d6c2f04d63932f4
                   |                            |859afac18

--- Comment #7 from Igor Kushnir <igor...@gmail.com> ---
Git commit b76e7a27aa2db2b0d6c2f04d63932f4859afac18 by Igor Kushnir.
Committed on 10/02/2025 at 14:30.
Pushed by igorkushnir into branch 'master'.

Sublime::MainWindow: don't disable updates while restoring state

>From the documentation for the property QWidget::updatesEnabled:
    Disabling a widget implicitly disables all its children. Enabling a
    widget enables all child widgets except top-level widgets or those
    that have been explicitly disabled.

A floating QDockWidget is a top-level widget (window). A non-floating
QDockWidget is not a top-level widget.

IdealController::addView() creates non-floating QDockWidget-inheriting
widgets with the main window as their parent. Then
Sublime::MainWindow::loadSettings() uses the HoldUpdates utility to
invoke on itself setUpdatesEnabled(false) before and
setUpdatesEnabled(true) - after the call to applyMainWindowSettings().
Before the call to applyMainWindowSettings() all dock widgets are
non-floating, so their updates become disabled along with their parent
main window's updates. KMainWindow::applyMainWindowSettings() calls
QMainWindow::restoreState(), which restores the floating property of all
of the main window's dock widgets. The dock widgets that are made
floating during the restoration become top-level widgets, so their
updates are not implicitly re-enabled after applyMainWindowSettings().

This bug manifests itself in practice as follows: when a detached tool
view is or becomes visible after switching to another sublime area or
after restarting KDevelop, its contents is not painted over whatever
pixels are behind it. One workaround is to remove and re-add the tool
view.

The disabling of main window updates in
Sublime::MainWindow::loadSettings() is useless, because no event loop is
entered in this function. And the loadSettings() function call does not
take long: 15-20 ms in a Debug build on my system.
FIXED-IN: 6.2.250400

M  +0    -4    kdevplatform/sublime/mainwindow.cpp

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

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to