https://bugs.kde.org/show_bug.cgi?id=372963
--- Comment #4 from Jan-Matthias Braun <jan_br...@gmx.net> --- Hi! I will try to dig through this, slowly... Right now I am trying to understand what happens in removeDesktop to trigger the Q_ASSERT in hopes that I find a good indication of what goes against expectations when the primary display switches away from the disconnected screen. So. In my case, when removing DP-0, removeDesktop is called with DesktopView: 0x19e2fd0 desktopView->screenToFollow()->name() is LVDS-0 [Comment: This seems reasonable, as the view on LVDS-0 is going to be replaced by the one from DP-0. On the other hand, removeDesktop was called by screenRemoved, where I would have expected the QScreen for DP-0 to be removed. Thus I am assuming now a mixup in the screen numbering, when the logical screen order is modified in terms of the primary screen. But as I have no clue of the underlying APIs, what they should do etc. pp., this is just a wild guess.] In the end, this situation leads to (after mapping via the ScreenPool) idx = 0 Now, I cannot say much on panels, as I don't use one for like 10 years. Thus I will ignore the next loop. Of course, the desktop view associated to idx via m_desktopViewforId now doesn't match the method parameter. Still, I don't what should happen in this case, e.g., should the primary view be transferred from the disconnected screen to the still available, or should the first view reconfigure itself to take on the contents of the other screen. Thus, I don't know if the assert is wrong. But as stated above, my intuition is, that the screen numbering in the internal representations mixes up. Hope this helps, Jan -- You are receiving this mail because: You are watching all bug changes.