| Summary: | Weird widget behavior | ||
|---|---|---|---|
| Product: | [Applications] kgeotag | Reporter: | 2tefan <me> |
| Component: | General | Assignee: | Tobias Leupold <tl> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | tl |
| Priority: | NOR | ||
| Version: | 1.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
2tefan
2024-06-16 18:45:41 UTC
Hi, thanks for your report! The docks shouldn't be closable in the first place ... at least, it's not possible to close them via mouse click (the features set are "QDockWidget::DockWidgetMovable | QDockWidget::DockWidgetFloatable", so QDockWidget::DockWidgetClosable is not enabled). If you can close such a floating dock nevertheless, this maybe depends on the window manager and I can't fix or prevent this at all (I think I can't do more than define that the docks are not closable) ... I'll have to investigate this. As a workaround, you should be able to recover all docks and their default position via "Settings" → "Set default dock arrangement". About the kgeotagrc: Current git master now uses KMainWindow's state instead of saving the state twice, so the state is now MainWindow/State. However, there will be a (now unused) main/windowState entry. Maybe, I'll add a quick check to remove this key later on to prevent confusion. Git commit 2d298421ab3f4d4f8c9e39f33e4f95ac3a4b7f92 by Tobias Leupold. Committed on 17/06/2024 at 09:50. Pushed by tleupold into branch 'master'. Be sure to actually show all docks when settuing the default arrangement M +5 -0 src/MainWindow.cpp https://invent.kde.org/graphics/kgeotag/-/commit/2d298421ab3f4d4f8c9e39f33e4f95ac3a4b7f92 Okay, this at least ensures that a closed dock widget is shown again when applying the default dock arrangement. However, I think this is an upstream bug: The dock widget should not be closable in the first place. I'll file an according kwin bug. FYI: I just filed Bug #488616 about this. I think I'll try to work around this by using a QDockWidget subclass that catches the QCloseEvent that should be ignored. I'm not sure if I can detect if the dock is closed because the program is quit or by using a shortcut to close it, but let's see. However, recovering such a closed dock is now possible by setting the default dock arrangement, so at least, we have a workaround. Hi, wow, thanks for the quick response! I have no experience with QT, but I suspected, that you explicitly left out `QDockWidget::DockWidgetClosable`, so it's not possible to close those widgets, I just wanted to add it as a workaround :) Also, thanks for the quick fix with the `Set default dock arrangement` button, that works great! Finally, thanks for filing those bug reports upstream, I am just amazed by how quickly everything went. Thanks for all the help!! Let's see where https://bugreports.qt.io/browse/QTBUG-126418 gets us :) You're welcome :-) The fact that the Qt guys already triaged this as "important" is maybe a good sign. I think I'll wait what they say. If this is fixed upstream, there's no need to implement a workaround. And for accidental closing of floating docks, we now have the "default arrangement" workaround to get them back. Well, let's see … I think I'll let this bug open as a reminder to check what upstream does now and then … Closing this as it's actually an upstream bug and we at least have a workaround. |