Age | Commit message (Collapse) | Author |
|
Change-Id: I4c9a2f9488a031b497c3ef87bcec9c1413002e23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151423
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I54d7376cb9b96164ed8c4526ef8f3a0502326f9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151365
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
so the code can be simplified
Change-Id: Iedbb844e5f11b993d73fb32d6871d74779919e10
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151368
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I96f8f676964920a9bf9c31d8fa81a17788f763af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151367
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
See https://gerrit.libreoffice.org/c/core/+/151262
Change-Id: Iecfc019d4b1eb16b572a13e8d9ad34088bd7bbba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151328
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Following an error in CppunitTest_chart2_export3 I updated
the transparency definition at WriteGradientFill and
corrected usages.
Had to correct/adapt some Chart UnitTests. Some of these
changes are temporary since this will/has to change when
ODF MCGR im/export is integrated. I checked that all of
these cases actually work, comparing im LO and MSO.
Adapted some Chart2ImportTest to directly compare/check
now for the fully imported tranparence gradient with
available higher precision.
Adapted OoxDrawingmlTest testGradientMultiStepTransparency
to use new MCGR capabilities.
Adapted testTextframeGradient and tested the turn-around
with rtf gradients. These are a little bit limited and
needed some extra care.
Adapted testTextframeGradient.
Adapted SdOOXMLExportTest1, testTdf94238
Adapted SdOOXMLExportTest1, testTdf128345GradientAxial
Adapted SdOOXMLExportTest2, testTdf105739
Adapted SdOOXMLExportTest3, testTdf127372
Adapted SdOOXMLExportTest3, testTdf127379
Adapted SdMiscTest, testFillGradient
Adapted testTextframeGradient
Adapted ScFiltersTest3, testTdf129789
Adapted SdUiImpressTest, testPageFillGradient
Adapted SdOOXMLExportTest1, testTdf128345GradientLinear by
using better double-to-integer rounding (basegfx::fround) in
DrawingML::WriteGradientStop. After double calculations
this makes the tansition to integer correct and stable. Also
took back change at testTdf128345ChartArea_CG_TS_export
which showed the same flaw before.
2nd look @testTdf128345Legend_CS_TG_axial_export made me
add that stuff again and adapt the axial ColorStop adding
in the export to not export the middle enty twice. Extended
test a little bit, too.
Only do not add value if it starts at 0.0 aka StartColor,
else adding it is corect.
Adapted some tests CPPUNIT_ASSERT to CPPUNIT_ASSERT_EQUAL
after being pointed to it from gerrit_linux_clang_dbgutil
build.
Change-Id: I4a993053da8960035671b655e67908f36e59b5fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150763
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Obsoleted by 2018 commit c6cf2320d2a464594e759289c34796538d31f02b
Change-Id: Ifc83b8dae06ef84d2ae276c18a395185db330cc0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150964
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: I9c1851d4c0520345d632ceef202f9991d2e6d359
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151262
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Ie857bc22f0340659612eb407975679953c538822
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151259
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: If0e64b6b4be769a485153465404370316d3f6587
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151162
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Regression from commit 0c0444c44107f1a18f23dd0833d462d8dbf56569
"tdf#126926 sc DBData: delete the database range".
Change-Id: I04923decdc768770f98763e60cd295400d15c769
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151065
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I43413ecb2ddf49676e7e446c6cdd1d4bfea7d8e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151088
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
This implements compact layout for pivot tables. In ooxml each row field
can have a compact layout setting. Support for any such "mixed" layout
of tabular/outline/compact per field is also implemented. This also
implements expand/collpse toggle buttons to field labels to make pivot
tables with compact layout more usable. Such buttons are also available
if other layouts are used.
Conflicts:
sc/qa/unit/pivottable_filters_test.cxx
sc/source/ui/cctrl/checklistmenu.cxx
sc/source/ui/inc/checklistmenu.hxx
Change-Id: Ieaa1f3bd282ebdec804d0b45a0af7b3d95a2027f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151057
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
This is a follow up to commit 3f614f431475e1bf3bb3bbeac59b0681309628b7
(tdf#95295: don't add duplicate conditional formats)
The above commit clearly describes how this fix works.
Change-Id: I064fb3fe0443705553c6bbfcc34f2d717e0f6bd6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150899
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Background color of shape inherited from theme
lost after export.
Regression from commit bc0a9076aa43a0782bcf81e55d3f84f6af0f68e8
"ooxml: Preserve shape theme attribute for solid fill".
Change-Id: I2d8298ac17332ba3ad6a627ce8b07c23087ac7b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150674
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Line properties (LineWidth and LineJoint) of shape
inherited from theme lost after export.
Perhaps regression from commit 5391d4872e71d1edba7acc4ad2d2e3b5b97e1723
"ooxml: Preserve shape style and theme attributes for line".
Change-Id: I9977bb20f16245f3c95ccbe2c5c8033b5b0c9cc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150547
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I1aa8e56fdbf0b8903cd04b78f4bb640fb31bd56d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150963
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
suggested by mike kaganski
Change-Id: I5f5f254142767aca45a6101abdd84a0163ca6a34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150936
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I263b143c94773045fa9c20471b81a7555aff4ce9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150909
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
idea from mike kaganski
Change-Id: I0ecb9cad091d7a048d2ddae73165bf22748f3872
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
To remove unneeded using declarations.
Via the simple script:
for i in $(find $dirname -name "*cxx" -o -name "*hxx" ); do
clang-tidy-12 --checks="-*,misc-unused-using-decls" "$i";
done
Change-Id: I596299084471b2904548d23875866f1583b00b2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150610
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
|
|
Change-Id: I1abf277223718ae2d650728e5bd141372a771a87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150590
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Regression from commit b9411e587586750f36ba9009b5f1e29fe461d8b5 where I
missinterpreted the check to get merged cells.
Regression:
tdf#147122 - Return cell object when a simple selection is merged
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145378
Change-Id: I2e39599a206cf102b1da8c7fc4bb2d8c0a4b106c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150412
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
The shadow of comments differs from the shadow of normal callout
shapes, as it shows only for the text rectangle. However the way
it's implemented is weird: The shadow attribute is set to false,
which turns off the "normal" shadow, and then the special shadow
is drawn unconditionally. There is also a code that forces the
shadow attribute to false on import, to handle some old files
that used to have the shadow on.
The confusion begins when one shows the comment, and looks at
right click > Area... > Shadow, which (rightfully) shows the
shadow as off, but doesn't align with what is visible on the
document canvas. Moreover, the other shadow settings on this page
do affect the comment shadow, but in order to change them it is
needed to check the "Use shadow" checkbox first. But leaving that
checkbox as checked will result with a double shadow being drawn
for the text rectangle, and an unnecessary shadow drawn for the
arrow part. The problem becomes now more visible, as there is
a Note style listed in the sidebar.
One possible approach could be to draw the special shadow only
when the shadow attribute is on, and patch existing files on
import to "shadow on" instead of "shadow off". But this will
cause the "double shadow" problem when opened in older versions
(unless the comment is hidden, in which case we used to override
the shadow attribute).
But now there's an opportunity for a better solution: As we
assign the default comment style to imported comments, we can
just clear the shadow attribute DF, instead of forcing it to
some value. As a result, the "shadow on" attribute of the style
will be in effect in newer versions, while in older versions it
will fallback to the "shadow off" pool default.
Change-Id: I4b35bc1e8e2e12ed35a82b0c2e9aabcf28b46270
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150353
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
... that don't have a style assignment. Typically in ods files
created by older versions or by 3rd party.
- For hidden comments this should make no difference, as we used
to apply the default comment formatting as DF underneath their
defined DF, just now we do that as a style assignment instead.
- Same for comments from xlsx and xls files.
- For visible comments from ods files created by OOo/LO, there
should be no difference either, as such files typically include
the shape formatting in them.
- For visible comments from ods files created by Excel, there
will be a difference, as Excel used to not include the full shape
formatting (known to be the case with Excel 2007 and 2016; can't
test any other version). This resulted with a weird look, e.g.
a line instead of an arrow, a default blue fill color and too
distant shadow, which clearly not how comments supposed to look.
Moreover, the comment will turn to transparent after hiding or
copying the cell, and will revert to the default look anyway
with resaving. Given that we were already enforcing the default
formatting for hidden comments and for foreign formats, I think
it's reasonable to do that for visible comments too (and in
general it's unclear to me why the ODF import treats visible
comments differently than hidden ones).
The main motivation of this change is to aid solving the shadow
issue - see the next commits.
Regarding the comment height change in the testCommentSize test:
This does *not* mean there is a change in that comment's import.
What this test does is to replace the existing comment with
a new comment, and that use the default formatting instead of
inheriting the formatting of the old one. But while the current
default formatting is whatever defined in the Note style, the old
default formatting was actually the draw pool defaults. This is
because we used to apply the comment formatting as DF, and the
relevant svx code (in SdrTextObj::NbcSetText) wasn't aware of the
fact that part of the DF was considered as default in this case.
Which means that this test was actually asserting a buggy behavior.
Change-Id: I37723cce3c719ecaa9c57bef25bcb168e353c55c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150489
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: Ic5b6099460bd5e978c04aff3233537059ce711b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150379
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Up to now the look of comments was maintained with the comment
shape's DF, with the default formatting being reapplied on
import (for hidden comments), on changing Tools > Options... >
LibreOffice > AC > Notes background, and on changing the
default cell style, while keeping the user-applied DF to some
extent. However, as we attempt to support drawing styles, this
approach is no longer viable, as applying DF on top of styles
at random times makes styles useless in the context of
comments.
(One might argue, that the look of comments should ideally be
treated as an app view setting, and not as a formatting of an
individual shape. This definitely makes sense, but has compat.
implications, as both LO and Excel allow formatting individual
comments (e.g. show a comment, right click > Area...). However
we will probably do it anyway if we ever implement threaded
comments like in recent Excel [1], as the callout shape based
approach seems to not scale to it.)
One way around it could be to explicitly disable any style
interaction with comments. But this will be unfortunate, as
styles have a clear advantage of being able to consistently
maintain the same formatting for several elements, much more
that the fragile approach of mixing the default formatting and
user-applied formatting in the same formatting layer. Not to
mention the possibility to define several custom styles. In
addition there is a request in tdf#55682 to disconnect the
formatting of comments from the default cell style, having a
dedicated style instead, which I find reasonable.
So this commit introduces a comment style, and uses it for new
comments instead of DF, making it easy to format all comments at
once. And a style based formatting is never overriden with DF,
unless explicitly set by the user. Changing Tools > Options... >
LibreOffice > AC > Notes background still has an effect in two
ways: (1) Sets the default background of the comment style for new
documents, and (2) if changed while a document is open, changes
also the comment style of the current document. An undo action
is also added, in case changing the current document wasn't
deliberate. Changing the default cell style no longer has any
effect on comment formatting.
One unfortunate side effect of this change, is that newly
created and permanently visible comments will lose their
default look when opened in an older version. But there is not
much I can do here, as older versions don't support styles, and
I believe the advantage of using styles outweigh this concern.
Hidden comments are not affected by this.
[1] see https://support.microsoft.com/en-us/office/the-difference-between-threaded-comments-and-notes-75a51eec-4092-42ab-abf8-7669077b7be3
Change-Id: I84215791b9e6ce393c6d979aa2b19ef70c76dff9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150352
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: I0bab920c78ff6d02382b9a314982a2f3d436b35a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150442
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I20efab10041cee570bd0685bbd4da6077a71f1e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150441
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: Ib27e0fa515eb69a56462f8571c37e314321924a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150298
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Otherwise, the function clearcontents does not accept the EDITATTR flag as a valid input.
Change-Id: I8381014da7110d060167a814d9ea02e347d5a92b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150191
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
This suite is large enough so that avoiding the
declaration/registration/definition of each test manually saves a lot of
space.
Change-Id: I4e2786f11bc1c164a74d3f5a3795a2ddf289d65f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150222
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Need to handle 3 cases:
- Import of hidden comments (not too much useful by itself,
as we still force the default comment formatting as DF).
- Copying cells with comments.
- The comment popup that is shown when hovering over a
comment marker.
Change-Id: Ibf2e22f1432745fe46f89da624ed3586b5d9fb55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149943
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
A formula containing a remote reference to a sheet including a
whitespace in its name does not correctly handle switching from
relative to absolute cell references using the EXCEL R1C1
formular grammar.
Change-Id: I3391f4e8f57993899b5e97f0a173b624b5ef0b22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150109
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
For all RANK(), RANK.EQ(), RANK.AVG().
Also, use #N/A NotAvailable instead of #VALUE! NoValue.
This made it necessary to adapt sc/qa/unit/data/ods/functions.ods and
result check that had a totally senseless query value with arbitrary
results.
Change-Id: If835b5ed49caf16a813b4ea897e1d7dd1aa02954
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150067
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Specifically in sd/source/core/annotations/Annotation.cxx
We seem to end up fixing leaks here often.
The current tools::JsonWriter API is just very hard to use correctly.
So rather return an OString, which is cheap to copy,
and push that down into the LOK code.
AFAIK that seems to end up requiring less code and less adhoc copying
of data (specifically the queueing code in init.cxx was creating
copies when converting to std::string).
Ideally, we could have some special API to avoid the new strdup()
calls in init.cxx, but not sure how to prevent other people
from accidentally using that.
Change-Id: Ia33437c1bfd9cc2d54dfb99914d1b72db20335f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149963
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
In addition, UI tests have been adapted to address the timeout of the search process.
Change-Id: Id9d78896e45da43734346654762c3541b8c07ba2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149958
Tested-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
Change-Id: I16321c8e22a205d211536b189191db453ebf1ce9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149956
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
and make it async
Change-Id: Idbf8661aa106d69e60ab6037052fd3d6dec28c06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149205
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149824
Tested-by: Jenkins
|
|
If the replaced string contains a newline after find and replace,
insert an edit cell in order to handle an embedded line correctly
regardless of the content in the source cell.
Change-Id: Ic8a5fc80b85546897572a228511b319cd5a8b9aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148752
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
This suite is large enough so that avoiding the
declaration/registration/definition of each test manually saves a lot of
space.
Change-Id: I60792ef623f6db275bf5b1346debceaa38fd6539
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149838
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I7c398c3dec044722e4552527de8553506cda54f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149730
Tested-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
Change-Id: If0ca5ea97ad545058c6a70d223158a87bf9207ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149729
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
Change-Id: I9a43b02caaad389d8f67a2d2d43ad555d131edf7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149645
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I907d234b20be5e3c7bee0d44407f1bf4c4b49f05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149175
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
after my patch to merge the bufferadd loplugin into stringadd
Change-Id: Ifa70db5be4719fe66d3043e5e49403246f6aa8bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149582
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This patch implements the mechanism to save solver settings in LO Calc as well as export/import them from XLSX files.
In MS Excel solver settings are saved as hidden named ranges, so in this patch I used the same strategy to save solver settings in Calc, i.e. by creating named ranges to store the solver settings using the same terminology used in Excel.
With this we gain the ability to save solver settings by tab, as well as export/import since we already have "named ranges/expressions" import/export implemented in LO.
Change-Id: Id41bca261dc3cd8e6888643f0ed6a97b26097876
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148112
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
It already has 99 tests
Change-Id: I672de980ce170b83ba84252170878731e1ce02f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149462
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Id92088a7d70c550682fe707d81e94157edc7caa8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149330
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: Ide679ada03dff5e62432d77b8c804d667bf2435b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148781
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149219
|