https://bugs.kde.org/show_bug.cgi?id=362964
Martin Gräßlin <mgraess...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |UPSTREAM
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Martin Gräßlin <mgraess...@kde.org> ---
(In reply to Marco Martin from comment #3)
> may be that the platform window of the dialog got destroyed but the instance
> of dialog is still around?
No, that's not the problem here. This is the typically "Qt, I'm too stupid to
handle multiscreen" crash.
The platform window fails to be created as the QScreen is null. Which is
totally, utterly stupid that Qt does allow QScreen to be null on xcb. That's
something that cannot happen! There is always at least a virtual screen. For to
me unknown reasons Qt decided to bind a QScreen to an XRandR screen - which
doesn't have anything to do what screens are in X11, but who cares. That way we
can get rid of all QScreens when e.g. all screens go into DPMS and then we can
make all windows crash at random code positions. Good that we didn't point that
out to Qt before they changed it. Just they ignored our advice and wrote
something like "then KDE needs to fix their code". What a pity that I never saw
a single backtrace ending in our code.
After trying to fix these crashes for about two years, Qt finally gave up in Qt
5.6 and introduced a dummy QScreen in xcb plugin. So with Qt 5.6 this problem
should be fixed. Till then, sorry, there is nothing we can do about it.
We unfortunately even had security vulnerabilities due to this utterly stupid
behavior of Qt.
Now, I am aware that e.g. Kubuntu LTS ships with this horribly broken Qt, so
please nag your distribution to update it.
End of rant on Qt's multiscreen problems.
--
You are receiving this mail because:
You are watching all bug changes.
