Bug 381310 - Tool views broken/not repainted when detached
Summary: Tool views broken/not repainted when detached
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: UI: general (show other bugs)
Version: 5.1.1
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Igor Kushnir
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-17 07:53 UTC by OlafLostViking
Modified: 2025-02-10 15:54 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.2.250400
Sentry Crash Report:


Attachments
screenshot of windows not repainted (274.96 KB, image/png)
2020-02-01 14:50 UTC, kde
Details

Note You need to log in before you can comment on or make changes to this bug.
Description OlafLostViking 2017-06-17 07:53:16 UTC
I have two monitors, but both with a resolution too low to show everything needed. So I open the "Variables tool view" in detachable state when debugging and move it onto the other screen.

When returning to Debug mode after working in Code mode, the tool view won't be redrawn anymore. It just "copies" the pixels underneath when opened. Since I know where the view should be, I can move and resize it but the initially copied "background pixels" stay there. To see the real content, I have to redock and detach it manually again.

Perhaps this can be solved by taking bug #377934 into account?
Comment 1 Francis Herne 2017-09-23 00:55:46 UTC
This is still reproducible with 5.2-git.
Comment 2 Sven Brauch 2018-11-27 16:33:16 UTC
Just reported again for 5.3.0 in #kdevelop.
Comment 3 kde 2020-02-01 14:50:46 UTC
Created attachment 125590 [details]
screenshot of windows not repainted
Comment 4 kde 2020-02-01 14:52:10 UTC
This is still present in the latest version from kdesrc-build. Is there some workaround? I am using non-compositing window manager, in case that makes a difference (marco on MATE desktop).
Comment 5 Igor Kushnir 2025-01-09 21:27:19 UTC
Just managed to fix this bug. Will create a large merge request with the fix included in a few weeks.
Comment 6 Bug Janitor Service 2025-01-24 19:59:40 UTC
A possibly relevant merge request was started @ https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/715
Comment 7 Igor Kushnir 2025-02-10 15:54:13 UTC
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