# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*- # # This file is part of the LibreOffice project. # # This Source Code Form is subject to the terms of the Mozilla Public # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/. # # This file incorporates work covered by the following license notice: # # Licensed to the Apache Software Foundation (ASF) under one or more # contributor license agreements. See the NOTICE file distributed # with this work for additional information regarding copyright # ownership. The ASF licenses this file to you under the Apache # License, Version 2.0 (the "License"); you may not use this file # except in compliance with the License. You may obtain a copy of # the License at http://www.apache.org/licenses/LICENSE-2.0 . # $(eval $(call gb_JunitTest_JunitTest,toolkit_unoapi_2)) $(eval $(call gb_JunitTest_set_unoapi_test_defaults,toolkit_unoapi_2)) # vim: set noet sw=4 ts=4: irtual and all subclasses except WinSalMenu::GetSystemMenuData having to override it to do nothing. Change-Id: Ia47af286f0fd3c1e3c6a00fff4512c9334fd6e9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177660 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins tdf#149805 tdf#151677 tdf#152217 tdf#154043 tdf#153458 tdf#153800 Revert "VCL expect 2023-03-29T10:46:00+00:00 Michael Weghorn m.weghorn@posteo.de 2023-03-24T07:06:56+00:00 f51b220b953ec71fb742f799fbe645a93cf3d944 ... correct frame size for native menubars" This reverts commit afc828b9833b7a612369e95606ba56d41ef2c369 Date: Sat May 28 23:47:21 2022 +0200 VCL expect correct frame size for native menubars ... and renove the wrong framesize hack in the Qt backend because it caused several regressions and unfortunately the commit also doesn't fix all of the bugs mentioned in its commit message (while some previous patch sets of the change did address more, yet had other issues, s.a. the discussion in the commit's Gerrit change [1]). While e.g. the drag and drop issues reported in tdf#153458 and tdf#153800 could be fixed by translating the event position using `mapToParent()` (as is done in `QtWidget::fillSalAbstractMouseEvent` with the above commit in place), I currently don't see how to address the other issues and the overall direction of the change is not fully clear to me at this point. (There are also other pending changes in the relation change still pending in Gerrit that would presumably need more work/analysis.) After all, it seems the best way forward to revert the commit for now. This also reverts the follow-up commit commit 25da92004038c03c0feedf373e8038e7ee3e0c37 Date: Thu Jul 21 11:33:02 2022 +0200 Make JunitTest_toolkit_unoapi_1 succeed again on macOS that fixed a test failure introduced by the above commit. Luckily, there seem to be no follow-up commits that depend on this and the commits can be reverted cleanly without the need to resolve any conflicts manually. This reverts commit 25da92004038c03c0feedf373e8038e7ee3e0c37. This reverts commit afc828b9833b7a612369e95606ba56d41ef2c369. [1] https://gerrit.libreoffice.org/c/core/+/135082 Change-Id: I4c099ad7de8cbbad10da391ede4770d8c748fbde Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149495 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> 
... correct frame size for native menubars"

This reverts

    commit afc828b9833b7a612369e95606ba56d41ef2c369
    Date:   Sat May 28 23:47:21 2022 +0200

        VCL expect correct frame size for native menubars

        ... and renove the wrong framesize hack in the Qt backend

because it caused several regressions and unfortunately
the commit also doesn't fix all of the bugs mentioned
in its commit message (while some previous patch sets of the
change did address more, yet had other issues, s.a. the discussion
in the commit's Gerrit change [1]).

While e.g. the drag and drop issues reported in tdf#153458
and tdf#153800 could be fixed by translating the event position
using `mapToParent()` (as is done in
`QtWidget::fillSalAbstractMouseEvent` with the above commit
in place), I currently don't see how to address the other
issues and the overall direction of the change is not fully
clear to me at this point. (There are also other pending changes
in the relation change still pending in Gerrit that would presumably
need more work/analysis.)

After all, it seems the best way forward to revert the
commit for now.

This also reverts the follow-up commit

    commit 25da92004038c03c0feedf373e8038e7ee3e0c37
    Date:   Thu Jul 21 11:33:02 2022 +0200

        Make JunitTest_toolkit_unoapi_1 succeed again on macOS

that fixed a test failure introduced by the above commit.

Luckily, there seem to be no follow-up commits that
depend on this and the commits can be reverted cleanly
without the need to resolve any conflicts manually.

This reverts commit 25da92004038c03c0feedf373e8038e7ee3e0c37.
This reverts commit afc828b9833b7a612369e95606ba56d41ef2c369.

[1] https://gerrit.libreoffice.org/c/core/+/135082

Change-Id: I4c099ad7de8cbbad10da391ede4770d8c748fbde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149495
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
VCL expect correct frame size for native menubars 2022-06-21T15:26:06+00:00 Jan-Marek Glogowski glogow@fbihome.de 2022-05-28T21:47:21+00:00 afc828b9833b7a612369e95606ba56d41ef2c369 ... 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 3f8d3fd4649ef09e86c735617383a4bda0425540 ("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> 
... 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 3f8d3fd4649ef09e86c735617383a4bda0425540 ("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>