I belive that the containerDestroyed shouldn't exist as there's also a containerEmpty method that will be called.
I belive both functions could be merged.

I think these do different things; containerEmpty is called when a container (Konsole window, presumably) closed its last tab but doesn't unregister the container. I'd guess that containerEmpty will be called first, and then containerDestroyed when the container is being disposed off (because it's empty).
There may not be an explicit current need to handle these separately, but I don't see why one should NOT do that.

Note that handling them separately will be necessary if container (Konsole window) is deleted via deleteLater() or otherwise not immediately after closing the last tab.

In D15295#320866, @rjvbb wrote:

I think these do different things; containerEmpty is called when a container (Konsole window, presumably) closed its last tab but doesn't unregister the container. I'd guess that containerEmpty will be called first, and then containerDestroyed when the container is being disposed off (because it's empty).
There may not be an explicit current need to handle these separately, but I don't see why one should NOT do that.

Note that handling them separately will be necessary if container (Konsole window) is deleted via deleteLater() or otherwise not immediately after closing the last tab.

It will not need to be handled differently, if in the containerEmpty() you do everything that's needed for the cleanup.
I say that because in one of my konsole branches I removed that and it indeed worked.
but I had so many stale konsole branches that I removed a few on a cleanup.

I say that because in one of my konsole branches I removed that and it indeed worked.

"it worked" to prevent crashing on exit? If so your approach would be an alternative fix.

But it really depends on whether or not containers are deleted immediately after the last tab is closed and/or on whether they need to remain registered until the last moment. That's something that the people working on tab/window management can say (they should also have an idea how this might evolve).

As long as I'm not 100% certain of this aspect of the design I prefer to consider merging the functions as a separate change.

It looks good fix to me, on containerEmpty should not unregister it, *logically*, furthermore it can be destroyed when it's not empty, it should be connected destroyed to containerEmpty too.

it should be connected destroyed to containerEmpty too.

I'm not sure I see why TabbedViewContainer::destroyed should be connected to SplitterView::containerEmpty; I think that would lead to calling containerEmpty too often.

What I can imagine is this: in containerDestroyed, check if the container being deleted is empty. If not, call containerEmpty directly *after* removing the container from _containers.

However, I notice these warnings when I close a Konsole window with multiple tabs open (here, 3):

shell did not close, sending SIGHUP
shell did not close, sending SIGHUP
shell did not close, sending SIGHUP

That could mean that the TabbedViewContainer dtor empties the container, and that could well mean that the empty signal is sent and containerEmpty is thus called?

Sorry for the delay; I thought this would be straightforward and then ran into questions...