https://bugs.kde.org/show_bug.cgi?id=356523
--- Comment #14 from Martin Klapetek <mklape...@kde.org> ---
> Any results here?
No.
@Thomas
> Actually™ you should not have to explicitly set the current geometry
I did some testing - if I remove this call completely, the placement is
fully random from what I can tell. if I simply replace
info.frameGeometry().topLeft()
with info.topLeft(), it still gets restored to a different position. Apparently
this is to some extent due to having QT_DEVICE_PIXEL_RATIO=2 as the
widget geometry is exactly half of what KWindowInfo reports, therefore
simply telling the QWidget to move to KWindowInfo geometry moves
it twice as much.
But not just that, I've tried something like
associatedWidget->move(info.geometry().topLeft().x() / 2,
info.geometry().topLeft().y() / 2);
but it would still restore it by some random pixels off.
What does, however, seems to restore it properly is this:
associatedWidget->windowHandle()->setX(info.geometry().topLeft().x()
/2);
associatedWidget->windowHandle()->setY(info.geometry().topLeft().y()
/2);
...where the "/2" should obviously be replaced by QT_DEVICE_PIXEL_RATIO.
But now tell me if this is a good and/or valid fix.
--
You are receiving this mail because:
You are watching all bug changes.
