How do I programmatically add a dock widget to a dock container widget? #394
Description
Hope you don't mind me posing this as a question.
I'm using ADS in a full-screen multi-monitor app, and to allow dock widgets to be docked into each monitor, I've set it up so that a CDockContainerWidget is created for each monitor, passing the dock manager into its constructor1.
This works great for letting the user dock widgets into each monitor, but I'm struggling to work out how to programmatically add dock widgets to these containers, in order to add a 'default' widget for each monitor.
What I've tried thus far, in case it helps
CDockContainerWidget::addDockWidget()seems to be the obvious API to do this, and it indeed works, except that the dock manager's map of docked widgets isn't updated to include the new one, causing, e.g. deserialisation to break.- The only place that seems to update this map (and emit a
dockWidgetAdded()signal) isCDockManager::addDockWidget()(and its related methods within the same class). However, this defaults to using the dock manager as the container, which can only be overridden by passing it aCDockAreaWidgetthat already exists inside the intended container – and as no dock widgets have been added to the container yet, the container doesn't contain any dock area widgets yet, and so I don't have one available to pass in.- Additionally, this method just forwards on to
CDockContainerWidget::addDockWidget(), which makes me unsure if the method onCDockContainerWidgetis intended to be used publicly…
- Additionally, this method just forwards on to
- I tried working around this by calling
CDockManager::addDockWidgetFloating()followed byCDockContainerWidget::addDockWidget()with the same dock widget, which will add it to the map, and add it to the dock container, deleting the floating dock container in the process. However, this apparently causes memory-related bugs within the library (namely, a pointer withind->UninitializedFloatingWidgetsbecomes dangling, potentially crashing the application insideCDockManager::showEvent()). While this feels like a bug within the library to me, this kind of workaround is bound to be fragile, so I'd rather not have to do something like this if it's possible.- Honestly, this is the approach I had implemented, until I became aware of the memory bug; in hindsight, I probably should've instead posed this question sooner, but ah well 🤦
Hopefully I've not missed something, but is there an intended way to add dock widgets to a dock container, such that the dock manager is made aware of the added dock widget? Or if there isn't currently one, is it worth adding a new addDockWidget()-style method to CDockManager that allows you to specify the container that the widget should be added to?
Footnotes
-
Technically, as
CDockManageris a subclass ofCDockContainerWidget, one of the monitors uses theCDockManageras its container, but I digress… ↩