Age | Commit message (Collapse) | Author |
|
Change-Id: Ifcdecb0a60f5a4b09acc83ed38b6d1ec46765ba6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105649
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
VCL implementations may have an optimized implementation,
and with Skia decomposing to polygons also causes drawing problems.
Change-Id: Ib1e317c627f01a43b77b9a8ee2335f4e319c37e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106016
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...more likely to pick an appropriate version for the involved integer types,
esp. after the recent long -> tools::Long changes
Change-Id: Ia91259ca35aaf74b0e907de6831fc926f30057f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105949
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This is only for the 64-bit windows platform.
I don't see the point in messing with the 32-bit platforms, they are
(a) become more and more rare
(b) unlikely to even have enough available process memory to load extremely large calc spreadsheets
The primary problem we are addressing here is bringing
Windows-64bit up to same capability as Linux-64bit when it
comes to handling very large spreadsheets,
which is caused by things like tools::Rectangle using "long",
which means that all the work done to make Libreoffice on 64-bit
Linux capable of loading large spreadsheets is useless on Windows,
where long is 32-bit.
The operator<< for tools::Rectangle needs to be inside
the tools namespace because of an interaction with the cppunit
printing template stuff that I don't understand.
SalPoint changed to use sal_Int32, since it needs to be
the same definition as the Windows POINT structure.
Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Iac1e7802dbe1efa01c2befdd10406231788d4fc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105315
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
since
commit 77809fba7d4bf5e0b604ffa3937c18d5530c2d56
Author: Luboš Luňák <l.lunak@collabora.com>
Date: Fri Oct 9 19:28:49 2020 +0200
implement ImplFastBitmapConversion() for 8bit gray source
Change-Id: I730aef10c1705ae6d3141014228cf79b8bfa3c63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105305
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The values returned from GetNativeSurfaceHandle are only used in
cairocanvas::CanvasBitmap::getFastPropertyValue
(canvas/source/cairo/cairo_canvasbitmap.cxx), whose consumers in turn are (at
least the ones I could identify):
* OGLTransitionerImpl::setSlides
(slideshow/source/engine/opengl/TransitionerImpl.cxx), passing the
values on to X11SalObject::SetLeaveEnterBackgrounds, which extracts the
Pixmap value to pass it on to XSetWindowBackgroundPixmap.
* X11SalBitmap::Create (vcl/unx/generic/gdi/salbmp.cxx), which extracts the
Pixmap value to pass it on to X11SalBitmap::ImplCreateFromDrawable (as a
Drawable) and to XFreePixmap.
While Pixmap XIDs are apparently 32-bit in the X11 protocol, see e.g.
<https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html>, Xlib and the
underlying /usr/include/X11/Xdefs.h appear to be somewhat confused whether the
typedef for XID should be unsigned long (presumably stemming from times when
long was universally 32-bit) or CARD32, see e.g. <https://gitlab.freedesktop.org
/xorg/proto/xorgproto/-/blob/master/include/X11/Xdefs.h>. So conservatively
stick to a 64-bit type here, even if it should only ever contain 32-bit values.
Change-Id: I26c3a2ff74cef092042a6e3648cd9a6f4a9e3aac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105144
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ide9811c1a7582454b3fcf655b70ea106ed56509a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104914
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ide4014348d51f0b5f59e1e91b8d41c7748853254
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104608
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
partly to flush some use of "long" out the codebase,
but also to make it obvious which units are being used
for angle values.
Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Perhaps AA may not look good with GDI or Xlib VCL, but with Skia
it is fine (and if it's not, I'll fix it).
Also avoid the repeated copy&paste.
Change-Id: I7aa60ae1e1c8a2ab4fa93d08ab0dfeb23c9c2cb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104437
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...after 1ebeacb20ad0165e399629fcfd7795ad0da3edf8 "Extend loplugin:cstylecast to
certain function-style casts"
Change-Id: I99bd383f5b3bee861d442d2e1be6ecd356b78315
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104523
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Most canvas implementations fall flat on their face when used
with Skia for various reasons, such as assuming presence of cairo
canvas or GDI bitmaps. I kind of already blocked them
in b4c28826e0f8716583e7663ca2ea7a2, when I just copy&pasted
the OpenGL case. That just selects the last implementation,
which in reality appears to be always vclcanvas, which is probably
just luck. Also this wouldn't work with more than one possible
canvas implementation for Skia.
Change-Id: If644abbaeed72f1a649f8974d00f564131aa9329
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103784
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Jenkins
|
|
Change-Id: I6c73e609cc8ce0ed9cf0f5a6b68c6e299bf26a44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103761
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
There's no point in trying to do all the stroking stuff manually
if the VCL function can do it and better/faster.
Change-Id: I9949637e2504d9b5d10ac77fbd5bd1f491ea6eee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103313
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
With the doc from tdf#136933 basegfx::utils::createNonzeroConform()
gets called with huge polygons, which is very expensive. Revert
this, I'll fix the Skia problem by directly trying to draw
the stroked polygon with VCL.
This reverts commit b0788ff11481568b413ff6e4c3ea4871984af974.
Change-Id: I19b3435811b6ea38d83bea08056802aac76bf45c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103312
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This renames AntialiasingFlags::EnableB2dDraw to just Enable,
and the AntiAliasB2DDraw names to just AntiAlias. This is
in preparation for a second commit that will actually separate
the AA and B2D functionality of these flags.
Change-Id: I9cc215c5752dfabce41e00e19d9074fc8dc3d4de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103416
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This reverts
commit 0cabffc05f3b40f5ee897df73475e09a3c05fc7
tools::PolyPolygon -> basegfx in canvas
and
commit 2c5d5a6d55a1ebd153f05523972a2c625484bde2
tools::PolyPolygon -> basegfx in filter
Comment from quikee:
The interpretation of integer polygons and floating point polygons
(or any other float vs. int drawing primitives) are different,
so you have to be really careful when changing, that the result
after the change is still the same. A big problem is that we still
have the metafile in OutputDevice, which is completely integer based
- so there will be conversions that go from int representation to
float representation to int again and to float (because backend is
in floating point) and I really fear that because of this there will
be regressions and even if not, it could make changing later more
painful. This is the reason I wouldn't change these things without
having tests that would show when there is a difference in rendering.
Change-Id: I54addca4e5a72196b5f77f6c7689eb716451c1dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103483
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7b5ac7b434932515895bf60acfa0109e6a2ebd18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103417
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Regression from commit 78036f74fa74ee2552e79064660634e1342692ff
(tdf#135094 cairo canvas: fix black slide containing a very small image,
2020-08-14), we try to predict when cairo would end up in an invalid
state due to an invalid transformation matrix, but in this case we were
too aggressive, so the image was missing while presenting.
Fix the problem by allowing negative sizes, just require that neither of
width/height is zero, because negative values are poor, but valid way of
vertical/horizontal flip.
[ No testcase, our tests are typically headless and currently
SvpSalGraphics::SupportsCairo() reports false, so this would be tricky
to test. ]
Change-Id: Iaf843c0d40c108d5221c9b94b39d617e4d50f65c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103127
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This commit was carried out by a Python script, source of which
is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97.
Change-Id: Icd712adf20fa2dbaaea2fc33a0fd870c8595b7e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100147
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
It passed "make check" on Linux
Change-Id: If7c189f410f08d5069edf0fc7a29057897e08388
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101617
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
It had been documented as "the macro OSL_THIS_FUNC is intended to be an office
internal macro for now", so take the liberty of removing it, even if technically
that can be considered an incompatible API change.
Change-Id: I7580a932e1da54845934378a650e894f3f3a9062
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101406
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Those polygons will be merged back in Skia because of
12147e0322e0fdd1b561c94e7ebd3fdd69ceaac0, which is costly with
tdf#135395. And if the only reason for the splitting is that
the polygon requires a winding rule but DrawPolyPolygon() uses
evenodd rule, then simply convert the polygon to the evenodd rule.
Change-Id: Iba5ec31d6d6407f734b20badc80c846071068d40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100976
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Don't paint when the area would be 0, that would not be visible anyway,
and the _cairo_matrix_to_pixman_matrix_offset() call would fail with
CAIRO_INT_STATUS_INVALID_MATRIX in _pixman_image_set_properties(),
failing the render of the whole slide.
Also, warn in case the painting fails, so the next time something
breaks, it's easier to find the problematic place.
[ No testcase, our tests are typically headless and currently
SvpSalGraphics::SupportsCairo() reports false, so this would be tricky
to test. ]
Change-Id: I7cdb9462ff8155232ea51abf321b365c2219575b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100743
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
look for expressions like
!(a && !b)
which can be expanded out
Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...assuming that such an exception is rare enough that any performance impact
does not matter. (The code was like this ever since its introduction in
9e2bf1d54a6e92dcfa3076bf4d7cc623ace87cd3 "INTEGRATION: CWS canvas02".)
This nicely avoids loplugin:unusedmember about unused mpStr and mnArgPos when
OSL_DEBUG_LEVEL is zero.
Change-Id: I2ad3e36e98a6811ae255525cf8159db89c78ad7f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100143
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Jenkins
|
|
Change-Id: I6512e6e4217ef9084c74e46e3b4f1e8defbd1bec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100108
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie28438633d9d81d756013772c573f02a756478d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100096
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I85149c0618a9b347fd1710f46b825844b3119bf4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100087
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iecdbbec18a8d88872878a8fa9a17f7040677384c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99863
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
In Skia mode, OGLTransitionerImpl::initWindowFromSlideShowView obtains
vclcanvas::SpriteCanvas from passed xView; it's passed to getDeviceInfo,
which needs a css::lang::XServiceInfo to fill the device params sequence.
vclcanvas::SpriteCanvas did not implement it, the sequence stayed empty,
and dereferencing its elements later crashed.
When Skia is disabled (VCL:win), xView provides a dxcanvas::SpriteCanvas
instead, which implements css::lang::XServiceInfo.
This makes vclcanvas::SpriteCanvas implement css::lang::XServiceInfo.
I don't know if it's better to find out why vclcanvas::SpriteCanvas is
used in Skia mode, and not dxcanvas::SpriteCanvas.
Change-Id: Ic0ab1323772161052a23946cfcc91e656ba6685c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99330
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Idc808459b403bcdcccbd86b73dd22b424e507c8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98897
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: Ie1f1736ceda372a53e1065d4829f019338f5b7bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98730
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: Id8d6ef240ba872f7e93752614cd2d45fc50897ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98729
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
regression from
commit 1cd0e02cdf7fc5b5903320ffd24865d11465d14b
cairo/canvas: create instances with uno constructors
Change-Id: I4d09f8d68a24b0efa47d12df1c542f2953efed3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98530
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It's much simpler and more performant to work with 8bpp bytes
rather than fiddle with 1bpp bits, and the memory savings don't
really matter nowadays. E.g. the soft edges feature performs
much worse when operating on 1bpp bitmaps (tdf#134237).
I've looked and it seems nothing in LO code actually requires
bitmap masks to really be 1bpp. As a next step we could perhaps
also leave antiquity and embrace the past by dropping 1bpp masks
entirely and using just alpha masks.
The change also moves the workaround for #i75531, it was breaking
CppunitTest_vcl_svm_test and X11-related hacks belong to the X11
code (especially with the X11 backend becoming more and more niche).
Change-Id: I7848f06c8b83bbad2ea35f17f2b65855f8d1f456
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97839
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
[API CHANGE] officecfg::Office::Common::Misc::OpenCLWhiteList -> OpenCLAllowList
Change-Id: I65636b19b13e4af1e4851f70e78053f3443d6bb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98181
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
.. and a few cases of instead doing blacklist->excludelist where that
made more sense.
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
[API CHANGE] officecfg::Office::Canvas::DeviceBlacklist -> DeviceDenylist
[API CHANGE] officecfg::Office::Canvas::BlacklistCurrentDevice -> DenylistCurrentDevice
[API CHANGE] officecfg::Office::Common::Misc::OpenCLBlackList -> OpenCLDenyList
Change-Id: Ia35e25496bf0cc0692d5de4cb66bfc232d3a869e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98180
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
See tdf#74608 for motivation
Change-Id: I02411b23136051bfd0cd02d5378297f99127017f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98189
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation
Change-Id: I2635df49edc2124f41a557110332ce5646cc59ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98093
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation
Change-Id: Ifcd31616228234433d8d46fef50707de9d17f3b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98092
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation
Change-Id: I2189622106e0c013567662c7bd81a057da65bf92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97935
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I14021d3e0b83dcd4fb5544239e982c8ada32d029
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97429
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
which is both more compact code, and more efficient, since the insert
method can do smarter resizing
Change-Id: I17f226660f87cdf002edccc29b4af8fd59a25f91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96948
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8a5029ef7aa6e8f46b13f0713445da435b47dbed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96209
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...as discussed as an open TODO in the commit message of
fe6cce01c88d045a1fcf09acf049c34c22299b02 "Fix loplugin:simplifypointertobool for
libstdc++ std::shared_ptr". The necessary changes across the code base have
been done fully automatically with the rewriting plugin on Linux. (All those
changes apparently involve uses of macro arguments wrapped in parentheses in the
macro body, but always in conditionally-converted-to-bool contexts. In other
contexts, such automatic rewriting would add the "bool" to the macro body, which
would be wrong in general, but we apparently get away with that sloppy coding
for now.)
The parenExprs_ stack that fe6cce01c88d045a1fcf09acf049c34c22299b02 had
introduced to treat such (then-undetected, it had turned out) parenthesized
cases now turns out to not be needed after all.
Change-Id: I2021f61c2e2805be7e18b38edf8744d186cac3cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95010
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib7c3b381ce4456e3d48538ee6f762ceaf2784fe1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94973
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...where the get member function is defined on a std::__shared_ptr base class,
so loplugin:simplifypointertobool used to miss those until now. (While e.g.
using libc++ on macOS found those cases.)
366d08f2f6d4de922f6099c62bb81b49d89e0a68 "new loplugin:simplifypointertobool"
was mistaken in breaking isSmartPointerType(const clang::Type* t) out of
isSmartPointerType(const Expr* e); c874294ad9fb178df47c66875bfbdec466e39763 "Fix
detection of std::unique_ptr/shared_ptr in loplugin:redundantpointerops" had
introduced that indivisible two-step algorithm on purpose.
The amount of additional hits (on Linux) apparently asked for turning
loplugin:simplifypointertobool into a rewriting plugin. Which in turn showed
that the naive adivce to just "drop the get()" is not sufficient in places that
are not contextually converted to bool, as those places need to be wrapped in a
bool(...) functional cast now. If the expression was already wrapped in
parentheses, those could be reused as part of the functional cast, but
implementing that showed that such cases are not yet found at all by the
existing loplugin:simplifypointertobool. Lets leave that TODO for another
commit.
Besides the changes to compilerplugins/ itself, this change has been generated
fully automatically with the rewriting plugin on Linux.
Change-Id: I83107d6f634fc9ac232986f49044d7017df83e2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94888
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I3234509406989661a2e5d3866bee057c17984437
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94738
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|