strepsirrhini/office-gobmx
9
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Fix some headless window sizes on Windows, to make make check more reliable

Browse source 
...by making it more resilient against varying screen sizes.  On my 2560x1600
Windows laptop, three `make check` tests systematically failed, and apparently
all of them were caused by that larger-than-average screen (similar to what has
been detailed in the commit message of 3db6a93c55
"Compute a better GetDefaultCenterPos"):

* CppunitTest_sw_layoutwriter
> test/source/xmltesttools.cxx:191:testTdf134298::TestBody
> equality assertion failed
> - Expected: 2
> - Actual  : 3
> - In <>, XPath '/root/page' number of nodes is incorrect

* CppunitTest_sw_ooxmlexport12
> sw/qa/extras/ooxmlexport/ooxmlexport12.cxx:526:testObjectCrossReference::TestBody
> equality assertion failed
> - Expected: Text 2
> - Actual  : 2

* CppunitTest_sw_uiwriter2
> sw/qa/extras/uiwriter/uiwriter2.cxx:2702:testTdf122942::TestBody
> equality assertion failed
> - Expected: 2
> - Actual  : 1

Those tests are all run with both SAL_USE_VCLPLUGIN=svp and --headless.  But svp
is only present on Linux and is thus ignored on Windows.  And --headless, while
preventing any windows from actually being shown, nevertheless uses the GUI code
to set up window sizes.  So the idea here is to hack the Windows backend in
strategic places so that it uses "appropriate" window sizes in --headless mode
to make `make check` succeed.

The Linux svp backend has a single place in vcl/headless/svpframe.cxx where it
hardcodes the number of monitors to 1 and the screen size to 1024x768.  However,
for the Windows backend, code determining and using those values is somewhat
spread, but it turned out that there is one strategic place in
ImplSalGetWorkArea that does what we want (without touching the reported number
of monitors at all), without (it appears) negatively affecting other scenarios.

(It appears that macOS, also not supporting an svp backend, is similarly
affected.  But it looks harder there to come up with such a strategic place to
hardcode --headless window sizes, and at least my own macOS build's `make check`
is unaffected as I use a default scaled 1829x1080 screen resolution there
instead of the "raw" 3840x2160.)

Change-Id: I822241f81497b9f6bed8e9688eddbe7d798c6b34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140588
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This commit is contained in:
Stephan Bergmann 2022-09-26 11:04:09 +02:00
parent 694f8eb1f7
commit 322ea272bb
4 changed files with 11 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
vcl/headless/svpframe.cxx
View file

@ -27,6 +27,7 @@
#ifndef IOS
#include <headless/svpgdi.hxx>
#endif
#include <salsys.hxx>
#include <basegfx/vector/b2ivector.hxx>

3
vcl/inc/headless/svpinst.hxx
View file

@ -32,9 +32,6 @@
#include <sys/time.h>
#define VIRTUAL_DESKTOP_WIDTH 1024
#define VIRTUAL_DESKTOP_HEIGHT 768
#ifdef IOS
#define SvpSalInstance AquaSalInstance
#endif

3
vcl/inc/salsys.hxx
View file

@ -82,6 +82,9 @@ public:
VCL_DLLPUBLIC SalSystem* ImplGetSalSystem();
#define VIRTUAL_DESKTOP_WIDTH 1024
#define VIRTUAL_DESKTOP_HEIGHT 768
#endif // INCLUDED_VCL_INC_SALSYS_HXX
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */

7
vcl/win/window/salframe.cxx
View file

@ -174,6 +174,13 @@ void WinSalFrame::UpdateFrameState()
// if pParentRect is set, the workarea of the monitor that contains pParentRect is returned
void ImplSalGetWorkArea( HWND hWnd, RECT *pRect, const RECT *pParentRect )
{
if (Application::IsHeadlessModeEnabled()) {
pRect->left = 0;
pRect->top = 0;
pRect->right = VIRTUAL_DESKTOP_WIDTH;
pRect->bottom = VIRTUAL_DESKTOP_HEIGHT;
return;
}
// check if we or our parent is fullscreen, then the taskbar should be ignored
bool bIgnoreTaskbar = false;
WinSalFrame* pFrame = GetWindowPtr( hWnd );