@n-elie Very nice! This would be very useful for our application!

I also wonder about how to best handle the case of a closing an area which has some docks with custom close handling (and cannot currently be closed for some reason) - ideal outcome: area does not actually close and the docks that cannot close stay present (but closable docks are no longer visible).

@nickdademo if you use the customclose flag, you need to connect to the closeRequested signal of the dockwidget and close it yourself. The problem with the current implementation is that this signal is sent only if there only one dock in the area

@nickdademo if you use the customclose flag, you need to connect to the closeRequested signal of the dockwidget and close it yourself. The problem with the current implementation is that this signal is sent only if there only one dock in the area

This is clear :) But what if the dock is not in a state to close (e.g. an operation inside the dock is in progress) when closing the area (i.e. in the custom close handling, we don't close)? So my question is: how to best handle this when closing the area.

Thank you for the pull request. I'm on vacation at the moment and will review your patch when I'm back next week.

@githubuser0xFFFF Did you have time to have a look to this? I would like to make this change to be able to ask the user to confirm he wants to close an area containing multiple widgets. With the current implementation, I can only show a message after the area has been hidden.

I just wanted to comment that I also was troubleshooting what I thought was a bug and now know is the intended current behavior (multiple dockwidgets not deleting on close as desired) . This appears to be exactly what we need for our use case as well!

@githubuser0xFFFF Do you see a way to achieve this goal that would better suit you? I would be happy to implement it

I think the PR in it's current state is OK and I'm looking forward to seeing it being merged :)

@n-elie I'm almost o.k. with the pull request. I think the flag DockWidgetForceCloseWithArea is o.k. and that it should close the dock widget, if the DockWidgetDeleteOnClose flag is set. But it should definitely not close any dock widget where the CustomCloseHandling flag is set even if the DockWidgetDeleteOnClose flag is set.

The CustomCloseHandling flag indicates, that the application is responsible for closing the dock widget and not the docking system. The docking system does not know anything about the content and state of the dock widgets where the CustomCloseHandling flag is set and should not close them.

@n-elie I'm almost o.k. with the pull request. I think the flag DockWidgetForceCloseWithArea is o.k. and that it should close the dock widget, if the DockWidgetDeleteOnClose flag is set. But it should definitely not close any dock widget where the CustomCloseHandling flag is set even if the DockWidgetDeleteOnClose flag is set.

The CustomCloseHandling flag indicates, that the application is responsible for closing the dock widget and not the docking system. The docking system does not know anything about the content and state of the dock widgets where the CustomCloseHandling flag is set and should not close them.

I think this PR won't force close these docks with custom close handling: CDockWidget::closeDockWidgetInternal will just return early without doing anything, right?

With the current implementation, when an area is closed and it contains only one dock widget, the closeDockWidgetInternal method of this widget is called no matter if the CustomCloseHandling flag is set or not.
So, I tried to keep with this behavior when closing multiple dock widgets.
Do we also need to test for the CustomCloseHandling flag for the "one dock only" case?

I just tested the PR and in works the way it should be - perfect. If you add the documentation for the the new flag to the user guide, I will merge the PR. Thank you.

Good to hear! I'm going to add this flag to the user guide. Thanks

I guess we are waiting for the user guide changes from @n-elie ?

Just added a few line in the README to describe the new flag. Not a native english speaker here, so feel free to edit

Thank you. I merged your pull request with some modifications.