Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.9.4, 5.13.1
-
-
3224c6d7d150164241c13ccf7d47377a39c0a6bb (qt/qtbase/dev) 87b83bf9931245b0ecc38fc52e69443b1d243176 (qt/qtbase/6.1) 3d5d5cbe71d9f556aac888353efe7c2b9b219b52 (qt/tqtc-qtbase/5.15)
-
Bug Fixing Candidates
Description
This is a Mac-specific problem.
We have an application with main window, MDI area, main tab bar at the top, and some dock windows. Several of the dock windows are locked to free-floating state, and these are not problematic. On top of this, we have four dock windows that are docked to the left in the default application state (but also allowed free-floating or docked to the right). On Mac, it has always been more or less impossible to re-dock one of the four if (willingly or accidentally) dragged to free-floating state. The only practically possible fix for misplaced dock windows has been to restore all user-made settings and go back to the default application state, which is far from always OK with the user.
This problem has been around with the same symptoms at least since Qt 5.5 and at least for Mac OSX versions 10.10-10.13.
This is the core problem that we need a fix for here, though we have made other observations when trying to use what measures there are in Qt APIs to limit the user sufferings from this buggy behavior - further comments follow in that direction...
Attachments
Issue Links
- is duplicated by
-
QTBUG-80215 Mac: Using QVideoWidget in a QDockWidget impacing the movement of other dockwidgets
- Closed
- relates to
-
QTBUG-30667 Changing the window opacity of a QDockWidget containing an openGL widget causes the titlebar widget area to not redraw.
- Reported
-
QTBUG-74606 floating QDockWidget with native child widget fails to show() after closing it
- Closed
-
QTBUG-64483 [macOS]: Calling winId() breaks the dock widgets
- Closed
-
QTBUG-90976 macOS: Calling winID on view port having Dockwidget breaks Dockwidget drag/dock etc
- Closed