Age | Commit message (Collapse) | Author |
|
with unique values so that, e.g.
if (pObj->GetObjIdentifier() == OBJ_LINE)
is only true if pObj is a SdrPathObj and not a E3dScene
Change-Id: I30c91e57eb27141390c644dec42e2a4bee96edf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105374
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
(*) create a rewriting plugin to do most of the work, heavily
based on the fakebool plugin
(*) but there are still a number of "long"s in the codebase
that will need to be done by hand
(*) the plugin needs lots of handholding, due to needing to
add #include and update macros
Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8379e5ebaee2090d2b4dbd05d55b55000915cd7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100233
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Turns out we can save about 500Mb of preprocessor input if we use
rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper
rtl::math::approxEqual from rtl/math.hxx
and manage the fallout accordingly.
Before:
bin/includebloat.awk | head
sum total bytes included (excluding system headers): 19017296671
After:
$ bin/includebloat.awk | head
sum total bytes included (excluding system headers): 18535432672
Change-Id: I1691171f3a309405a7099882ad9989d147f59118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
so rectangles can be constructed already valid
Change-Id: I3ae5e24add3c81f79dcdf863f855dca439876f11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92521
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 1a6397030381a45f27ab7a2a02e6e6d0f9987c84.
Change-Id: Iaa706bb4ea3144ef57ab359b982400abc589b97e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90454
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Except for already done svx/source/sdr/
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I1c4b34cf42aa9faa2f7de36fe1602059460c6c1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89656
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I8d9a50039a8139caebb2cfb83ca476d39432f255
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88238
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I checked return values.
Long variables didn't affect the calculation.
Change-Id: I0c33c20b872ff6b1dc6c87c4032ccf19705db8e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87503
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Covers tdf#98583 and tdf#98565 too.
TRBaseGeomety (API) uses for skewX the same angle orientation as
written to file. But that results in mathematically wrong matrices.
Change sign where needed.
Vertical shearing is converted and written to file by LO as sequence
rotation * shear horizontal * scale. Same should happen on reading.
Because LO does not write skewY itself, I have used the angle
orientation, that was used in OOo1.1.5 and that is used in
Scribus 1.5.4.
Import generates a transformation matrix from the draw:transform
attribute. That is a mathematically correct matrix. It is applied
to the shape via TRSetBaseGeometry. But that uses a wrong sign in
the shear angle. Therefore conversion of mathematical matrix to
TRBaseGeometry matrix is needed.
The draw:transform attribute can generate a scaling, which needs to
be applied on top of the scaling made from svg:width and svg:height.
Such happens on import of skewY() and might happen with matrix().
SdrPathObject puts scaling form svg:width and svg:height directly
into the coordinates of its points. It had ignored any additional
scaling. I have add a part to detect and apply it.
Change-Id: I7636b9feec432cf403e7c6ef8dbd6a769793d144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86244
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and make it return the result, rather than doing it via an awkward
out-parameter
Change-Id: Ia47c66b4f1bae781a679f2f4311e321fdc947928
Reviewed-on: https://gerrit.libreoffice.org/80547
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia7f9ff4d8f7b9834b6634e5c126bd65014dacf19
Reviewed-on: https://gerrit.libreoffice.org/78684
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7995bb3e8732ec20b941bd029e5a77aa78d09592
Reviewed-on: https://gerrit.libreoffice.org/78673
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I24b53dceb79bd43aed92c8130dc33b637410d231
Reviewed-on: https://gerrit.libreoffice.org/78672
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 26001f4f84b0d921c8612d888856613735ba5314.
Change-Id: Ib4df476b405e65be9203ab376c9c68b03198c040
Reviewed-on: https://gerrit.libreoffice.org/77882
Tested-by: Regina Henschel <rb.henschel@t-online.de>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: I45e26c9cdc00ae6d3bc56534d612b83b5ac26074
Reviewed-on: https://gerrit.libreoffice.org/72125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I04289589196ac69b31f75989d9252c79d03c890f
Reviewed-on: https://gerrit.libreoffice.org/71633
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Please feel free to suggest a better name, if desired
Change-Id: Ia5b7b6100fc588ba366ed31e249e35ce501e0d1a
Reviewed-on: https://gerrit.libreoffice.org/70372
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: I7c061e242f24e4aa65064e74121318580c0bbf72
Reviewed-on: https://gerrit.libreoffice.org/68527
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ia2c103a5b530d007f750e4a034b253b3ec5406ec
Reviewed-on: https://gerrit.libreoffice.org/68368
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
since it is just a wrapper around PointerStyle
Change-Id: I51f065e0d4ad8bd91f5c84c5819048c720a19267
Reviewed-on: https://gerrit.libreoffice.org/67711
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Since it is now possible to use C++14, it's time to replace
the temporary solution with the standard one
Change-Id: Ic91b7170b10299001167e78ade1d24c16ce9319e
Reviewed-on: https://gerrit.libreoffice.org/67475
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
...after 7ffdd830d5fb52f2ca25aa80277d22ea6d89970b
"HAVE_CPP_ATTRIBUTE_FALLTHROUGH is always true now"
Change-Id: I54e5ff4e036a6bb3e5774d1c0524158aae18e937
Reviewed-on: https://gerrit.libreoffice.org/64800
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
A polygon consists of line segments without controls and curve
segments with two controls. Where two segments meet, can only be
'line to line', 'line to curve' or 'curve to curve'. So for a
handle which marks a meeting point of two segments, there are 0
or 1 control before and 0 or 1 control after. Thus a loop is not
needed and makes the code harder to read. Therefore I have
removed the loop.
Change-Id: I48bcdbdf028542e08b3f5ed3f66907f2993e26bd
Reviewed-on: https://gerrit.libreoffice.org/63036
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
regression from
commit f74b888244fcefa7c03fa25db4d42c839ebbf642
simplify PlusHdl logic
restore the structure of the original code here, which is completely
opaque to me
Change-Id: I7b9e5732bd7ed0a92627503ea3c7d2d320a8a33b
Reviewed-on: https://gerrit.libreoffice.org/62989
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I27f4dd0cb08f9b62496a1c51eed732a678e1c2e5
Reviewed-on: https://gerrit.libreoffice.org/62252
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
avoid copy when adapting polygon in SdrPathObj::ImpForceKind()
Change-Id: Ifd830ecd181563102ee269c6a609ef8ebeab670c
Reviewed-on: https://gerrit.libreoffice.org/61767
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...where "inline" (in its meaning of "this function can be defined in multiple
translation units") thus doesn't make much sense. (As discussed in
compilerplugins/clang/redundantinline.cxx, exempt such "static inline" functions
in include files for now.)
All the rewriting has been done automatically by the plugin, except for one
instance in sw/source/ui/frmdlg/column.cxx that used to involve an #if), plus
some subsequent solenv/clang-format/reformat-formatted-files.
Change-Id: Ib8b996b651aeafc03bbdc8890faa05ed50517224
Reviewed-on: https://gerrit.libreoffice.org/61573
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I643e8686e015ca85dd96221f1c93038f4fddf27b
Reviewed-on: https://gerrit.libreoffice.org/61182
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I83241bd2ed172594704f4b115b584dc39b234086
Reviewed-on: https://gerrit.libreoffice.org/60959
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
like we did with the AddToHdlList stuff, all the client code cares about
is fetching the entire list
Change-Id: Id3cefa5f316a3f979a276c64f9125943d0981842
Reviewed-on: https://gerrit.libreoffice.org/60813
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
the code already says that using GetHdl is inefficient, and client code
should be using AddToHdlList, so just drop the bad one
Change-Id: I88c43154c8cc0988127b9292e4cda28917f54eb9
Reviewed-on: https://gerrit.libreoffice.org/60792
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia20fac7cec01ac658a903f8b001807b2e72dbf3e
Reviewed-on: https://gerrit.libreoffice.org/60316
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
with document ooo47086-1.xls
Change-Id: Ia43b6b3e3951875280892138c7068348f1b56a7c
Reviewed-on: https://gerrit.libreoffice.org/58913
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Act -> Current
Not a translation per se, but correction of usage of "actual"
(German: "wirklich") instead of "current" (German: "aktuell").
This is similar to the Akt -> Current translation done on
commit b62ac98a72e21d49aec4493ace8ba12b7561439d in the same file.
Change-Id: I462106ee5d2b07b09bb567b962bcb97d76859d81
Reviewed-on: https://gerrit.libreoffice.org/58873
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Also rename svx angle normalization functions in include/svx/svdtrans.hxx, that
deal with 100ths of degree, to avoid confusion: NormAngle180 -> NormAngle18000;
NormAngle360 -> NormAngle36000.
Some places were fixed that previously returned inclusive ranges (i.e., both 0
and 360), see changes in these files:
chart2/source/view/main/PlottingPositionHelper.cxx
chart2/source/view/main/PolarLabelPositionHelper.cxx
chart2/source/view/main/ShapeFactory.cxx
filter/source/graphicfilter/idxf/dxf2mtf.cxx
sw/source/core/graphic/grfatr.cxx
(the latter now matches the comment in the function).
Change-Id: I9f274bbb4168360d60dceff02aeba6332c519a59
Reviewed-on: https://gerrit.libreoffice.org/58556
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Idb8d16f59823d9065b82d6312def36601457af1a
Reviewed-on: https://gerrit.libreoffice.org/58546
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it.
This is a continuation of commit 6ff2d84ade299cb3d14d4110e4cf1a4b8070c030 to be able to remove those unneeded includes.
This commit adds missing headers to every file found by:
grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG')
to directories from stoc to svx
Change-Id: If562b1aa1d676d2c1cf513e953238abbb846c65c
Reviewed-on: https://gerrit.libreoffice.org/58224
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Id59caa7da8fdfd613eb3b97196c52131aeb7378c
Reviewed-on: https://gerrit.libreoffice.org/58375
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>
|
|
Change-Id: I0cc0c32afa0d735738c6744873f3518a2763821e
Reviewed-on: https://gerrit.libreoffice.org/58334
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0fed54d345a43fe0bc21ebbe424e6fdc7eac9523
Reviewed-on: https://gerrit.libreoffice.org/56823
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
SvxShapePolyPolygonBezier was an implementation for the UNO
Shape group of polygons with bezier parts (filled/unfilled/
closed/open), e.g. com.sun.star.drawing.OpenBezierShape.
It was differing from SvxShapePolyPolygon just by supporting
drawing::PolyPolygonBezierCoords instead of the simple
drawing::PointSequenceSequence and some details.
This leads to problems - the ShapeType *does change* e.g.
when you edit a non-bezier Shape in Draw/Impress and change
parts to curve (also when closing, see ShapeTypes above).
This is why SvxShape::getShapeType() already detects this
identifier by using thze internal ShapePolyType (e.g.
OBJ_PATHLINE).
So there is no reason to have two separate UNO API imple-
mentations for sthe same type of SvxShape at all. Get rid
of the extra one and unify this implementation detail.
Also cleaned up double basegfx tooling for conversions of
UNO API Poly/bezier data and B2DPolygon.
Adapted test for "tdf113946.docx", see comment there.
Adapted test for "tdf90097.rtf", see comment there. Also
needed to use the Linux values, also check comment there.
Adapted test for "tdf105127.docx", see comment there.
Adapted test for "tdf85232.docx", see comment there.
Had to fic a problem with test for "tdf96674.docx"- the
adaption of the RotateAngle for line objects goes havoc
together with the UNO API when scaling is involved. That
old aGeo rotate stuff just kills the existing rotation due
to numerical inprecise stuff. The UNP API - in trying not
just to apply a rptation, but manipulate the existing one
then goes wrong in not re-getting the current rotation
value anymore. ARGH! This is the original reason for the
ols tdf#96674 task - i doubt that the additional code to
make a line not exactly hor/ver is needed.
Checked and it is not needed, thus removed the change from
tdf#96674 in shape.cxx.
Change-Id: I2bb8d4cfe33fee3671f3dad60e5c18609a394f9d
Reviewed-on: https://gerrit.libreoffice.org/56614
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
Change-Id: I7d9966d11f8272034523d9804ecf76e119552780
Reviewed-on: https://gerrit.libreoffice.org/55796
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie0fb647938e3cf730976fb2e435b92bfd67ef645
Reviewed-on: https://gerrit.libreoffice.org/54998
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I10c291788061ec8467126a0dc719e20fb3cf47ec
Reviewed-on: https://gerrit.libreoffice.org/54386
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Renamed SdrPage::Clone -> SdrPage::CloneSdrPage
Renamed SdrObject::Clone -> SdrObject::CloneSdrObject
Giving SdrModel is no longer an option, but a must (as
reference). This makes future changes more safe by force
usage to think about it. Also equals the constructors
which already require a target SdrModel.
Done the same for ::CloneSdrPage.
Change-Id: I06f0129e15140bd8693db27a445037d7e2f7f652
Reviewed-on: https://gerrit.libreoffice.org/53933
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
In current versions MapMode handling is done in ::TRSet/Get-
BaseGeometry methods. These belong to SdrModel level and
should not do any MapMode conversions (else all geometry
and Rectangle setters/getters should have to do these, too).
Instead, the UNO API implementation should do these, there
are already some done there and this is the level which offers
pure 100ThMM handling to the caller, independent from the
used application.
Change-Id: I3d7781440fc0fc6a20b5d4e79c747c988677483d
Reviewed-on: https://gerrit.libreoffice.org/53748
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
This is a wrapper above SvxResId without added value
Change-Id: I1b0cdad3c01e741df1032d6a13aea74d66502144
Reviewed-on: https://gerrit.libreoffice.org/53489
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|