... and renove the wrong framesize hack in the Qt backend
This wastes a few additional pixels in the frame backing store,
actually covered by the real native menu bar, to get rid of all
the hacks and eventually fix quite a bunch of bugs in Qt (and
maybe other backends).
This seems to work correct with Qt using either QPainter or Cairo
as the painting backend. It's much simpler then my previous failed
attempts to fix the Qt related bugs. I would like to convert every
implementation to my interpretation of the API (at least I now
documented the API). It looks like Win and Mac will just work,
because Win has no native menu bar and Mac uses a global menu,
so always returns the size of 0. And Gtk also seems to work, if
it also lies about the menu bar size being zero. That just seems
consequent, if the frame size is reduced by the menubar size.
This fixes at least:
tdf#64438 - Dockable panels in LibreOffice not dockable using KDE
Works.
tdf#130893 - XWindow::SetPosSize resizing based on
XWindow::GetPosSize shrinks the window
The document macro from tdf#130841 now doesn't resize the window.
This is just fixed for Qt.
tdf#134704 - KDE5 - unable to dock sidebar by dragging frame
not fixed, because the sidebar window is now a dialog, which is
not dockable. FWIW the same has happend the Navigator (F5), which
also renders it non-dockable. No idea, if this is intentional.
tdf#137471 - CMIS dialog advances beyond lower right corner of the
screen
So commit 3f8d3fd464 ("tdf#137471 Qt
return frame pos + client area size") was really not enought as a
fix (at least it didn't break anything). The whole parent-based
repositioning is wrong and it really depends on the correct frame
size, so I'm keeping this as fixed by this patch.
Change-Id: I7faeace61b456c2b0f42c7a826f58018b70d46ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135082
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
afc828b983