Age | Commit message (Collapse) | Author |
|
We create a bunch of temporary copies of these during layout in writer,
and we don't appear to need the equation results at that point.
Speeds up display of a complex DOCX file load by 10%
Change-Id: Ic5870931caba13cd79b07617d04b70616f06c5b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170498
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: I6727def5dd42ecd5dae3ddd27d2af733b5883e09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170006
Tested-by: Jenkins
Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de>
|
|
See tdf#94879 for motivation.
Change-Id: I88eaa11f4eaca381a9cb95aa2f24b5a43c7ca80d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153246
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Which means we can get rid of the majestic hack of ScCaptionPtr
Previously, SdrObject was manually managed, and the ownership
passed around in very complicated fashion.
Notes:
(*) SvxShape has a strong reference to SdrObject, where
previously it had a weak reference. It is now strong
since otherwise the SdrObject will go away very eagerly.
(*) SdrObject still has a weak reference to SvxShape
(*) In the existing places that an SdrObject is being
deleted, we now just clear the reference
(*) instead of SwVirtFlyDrawObj removing itself from the
page that contains inside it's destructor, make the call site
do the removing from the page.
(*) Needed to take the SolarMutex in UndoManagerHelper_Impl::impl_clear
because this can be called from UNO (e.g. sfx2_complex JUnit test)
and the SdrObjects need the SolarMutex when destructing.
(*) handle a tricky situation with SwDrawVirtObj in the SwDrawModel
destructor because the existing code wants mpDrawObj in
SwAnchoredObject to be sometimes owning, sometimes not, which
results in a cycle with the new code.
Change-Id: I4d79df1660e386388e5d51030653755bca02a163
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138837
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
A shape might have the shading information not in commands in the
enhanced-path, but generated in ctor of EnhancedCustomShape2d from the
Type value of the shape. This shading information is a 32 bit value
with first the number of the shadings and then the shadings. A shading
is encoded with 1,2,3,4,5,6,7 for lighten 10 to 70 and 8,9,a,b,c,d,e,f
for darken -80 to -10.
To get this information from EnhanceCustomShape2d I have made its
method GetLuminanceChange() public.
Because OOXML only has darken, darkenLess, lighten and lightenLess our
values are mapped:
-10, -20, -30 to darkenLess
-40, -50, -60, -70, -80 to darken
10, 20, 30 to lightenLess
40, 50, 60, 70 to lighten
The bupreport mentions only 'Octagon Bevel' and 'Diamond Bevel'. But
the patch fixes missing shading for shapes of Types 'ActionButton*'
as well. Such shapes come in from MS binary import.
Change-Id: I03f19496b915f3ced6346222e8806832b4ee2827
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133220
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
improve the plugin to detect more cases.
I only apply the new final changes to classes in /include here.
Which reveals that
RoadmapWizard::getPageController( TabPage* _pCurrentPage )
will always return nullptr
Also needed to sprinkle some
SAL_DLLPUBLIC_TEMPLATE
around to workaround Visual Studio linking problems.
Change-Id: Iadb7d46a9e0e73dabce562375ca013c0fea6690c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117365
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and fix some leaks in the unit tests
Change-Id: I8d324a24de11b14b4820e3cdd7f078d5877489e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110288
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I78f837a1340be0ca5c49097f543a481b7b43a632
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108367
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>
|
|
Using SVX_DLLPUBLIC for both Library_svxcore and Library_svx had started to
cause failures with clang-cl on Windows now, presumably due to devirtualization:
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::DataChanged(class DataChangedEvent const &)" (?DataChanged@SvxMetricField@@MEAAXAEBVDataChangedEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::PreNotify(class NotifyEvent &)" (?PreNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::EventNotify(class NotifyEvent &)" (?EventNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::Modify(void)" (?Modify@SvxMetricField@@MEAAXXZ)
> linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::PreNotify(class NotifyEvent &)" (?PreNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::EventNotify(class NotifyEvent &)" (?EventNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z)
> C:\lo-clang\core\instdir\program\svxcorelo.dll : fatal error LNK1120: 6 unresolved externals
Replacing certain uses of SVX_DLLPUBLIC with the newly introduced
SVXCORE_DLLPUBLIC (include/svx/svxdllapi.h) has been done on Linux as follows:
> git grep -w --line-number -e SVX_DLLPUBLIC --and --not -e '#define SVX_DLLPUBLIC' >LINES
to produce a file LINES containing all 640 uses. (Conveniently, all uses
happen to be on different lines.) Manually create a file TOKENS
with 640 corresponding lines, each containing the (class or function) name that
is made SVX_DLLPUBLIC by in the corresponding line in LINES. Then
> nm -D --def instdir/program/libsvxcorelo.so | grep -ivw '[vw]' | c++filt >SVXCORESYMS
> nm -D --def instdir/program/libsvxlo.so | grep -ivw '[vw]' | c++filt >SVXSYMS
> n=$(cat TOKENS | wc -l)
> for ((i=1;i<="$n";++i)); do
> tok=$(head -n "$i" TOKENS | tail -1)
> printf @
> grep -Fw "$tok" SVXCORESYMS >/dev/null && printf svxcore
> printf @
> grep -Fw "$tok" SVXSYMS >/dev/null && printf svx
> printf '@ '
> head -n "$i" LINES | tail -1
> done
to generate 640 output lines detailing for each SVX_DLLPUBLIC name occurrene
whether it is mentioned in exports from neither (@@@), only from svx (@@svx@),
only from svxcore (@svxcore@@), or from both libraries (@svxcore@svx@). The
numbers that gives is
10 @@@
180 @@svx@
424 @svxcore@@
26 @svxcore@svx@
The 10 @@@ ask for follow-up clean up, but most of them are just left as
SVX_DLLPUBLIC for now. The exceptions are sxv::ITextProvider
(include/svx/itextprovider.hxx) and SdrCustomShapeGeometryItem::PropertyPairHash
(include/svx/sdasitm.hxx, where PropertyPairHash is a member struct of
SVXCORE_DLLPUBLIC SdrCustomShapeGeometryItem). Keeping them as SVX_DLLPUBLIC
would cause "unresolved externals" errors when linking Library_svxcore on
Windows.
The 180 @@svx@ are fine to keep as-is, and the 424 @svxcore@@ need rewriting.
The 26 @svxcore@svx@ needed manual inspection to decide (in some cases, the
chosen name in TOKENS was a too generic function name like Fill, in other cases
it was the name of a class exported from one library but also mentioned in the
arguments of a function exported from the other).
And for sdr::table::SdrTableObj the class itself is defined in svxcore while the
static member functions ExportAsRTF and ImportAsRTF are defined in svx. But
MSVC does not allow to mark the class as SVXCORE_DLLPUBLIC and the two static
member functions as SVX_DLLPLUBIC, so move the two functions out of the class.
(There appears to be no real necessity that they were static member functions in
the first place; they don't even need to be friends of the class. Nevertheless,
this mixture of functionality from svxcore and svx in include/svx/svdotable.hxx
may ask for follow-up clean up, one way or another.)
All the output lines that need rewriting (all the @svxcore@@ ones, and the
manually picked subset of @@@ and @svxcore@svx@ ones) are copied into a new file
CHANGE (containing 451 lines). Then
> sed -E -e 's|^@.*@.*@ ([^:]+):([0-9]+):.*$|sed -i -e "\2 s/SVX_DLLPUBLIC/SVXCORE_DLLPUBLIC/" \1|' <CHANGE >COMMANDS
> . COMMANDS
to do the changes.
Change-Id: If9b6dd1c9e9ba2eb883dbdac4385d28c6fc8a203
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87794
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I6ae7c04479e3ea8ecd7535c33224a5e7095b64bb
Reviewed-on: https://gerrit.libreoffice.org/78396
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...when instantiating implicitly defined special member functions of
SVX_DLLPUBLIC EnhancedCustomShape2d, due to seqSubViewSize member
Change-Id: I7dd22ba0602461c1bbe2e1e5351e161f2e098c37
Reviewed-on: https://gerrit.libreoffice.org/73404
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I861d3f0fa15ee3b7e0e830c4fac2e5794ea4071b
Reviewed-on: https://gerrit.libreoffice.org/72213
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
The current solution uses one, bad valued Bezier curve and does not
toggle direction. The patch uses the more accurate solution from
basegfx and simplifies the decision tree. In addition it extracts the
calculation in double from GetPoint, so they can be used directly
instead of double->long->double conversion.
Change-Id: I298f49415d1b7624b36ca561647f2e58af5eb5c6
Reviewed-on: https://gerrit.libreoffice.org/65203
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: I643e8686e015ca85dd96221f1c93038f4fddf27b
Reviewed-on: https://gerrit.libreoffice.org/61182
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Changed quite some places of SdrObjCustomShape usage to use
references instead of pointers, thus forcing to more secure
handling. Changed some test and change methods, even found a
memory leak by doing so.
Added some incudes/predefines for linux builds.
Change-Id: Iba76037a3c54af50bb05e6bd63d7ad04624665a7
|
|
Changed quite some places of SdrObjCustomShape usage to use
references instead of pointers, thus forcing to more secure
handling. Changed some test and change methods, even found a
memory leak by doing so.
Change-Id: Iba76037a3c54af50bb05e6bd63d7ad04624665a7
|
|
There was a member at SdrPathObj called mdBrightness only for
holding a blend value during creation of SdrPathObjs for
CustomShape visualization. This has nothing to do on the
model data, move it to where it belongs
Change-Id: Iee101f90a1275ce1ed97e8e8d0ccf7084c83d4f6
|
|
Change-Id: I30f371ad301eede82ddcece4d91ffcd32e164115
Reviewed-on: https://gerrit.libreoffice.org/42598
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: Iaaf9092ec4d6189492906648b84494d087fed81f
Reviewed-on: https://gerrit.libreoffice.org/41539
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7fc5bf55b01d464815771220914f21d8e85b5a36
Reviewed-on: https://gerrit.libreoffice.org/40253
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Mostly generated using
make check COMPILER_EXTERNAL_TOOL=1 CCACHE_PREFIX=clang-rename-wrapper RENAME_ARGS="-qualified-name=Rectangle -new-name=tools::Rectangle"
Except some modules have their own foo::tools namespace, so there have
to use ::tools::Rectangle. This commit just moves the class from the
global namespace, it does not update pre/postwin.h yet.
Change-Id: I42b2de3c6f769fcf28cfe086f98eb31e42a305f2
Reviewed-on: https://gerrit.libreoffice.org/35923
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I81f5d1ca22868d278662a55443e2038581dd3246
Reviewed-on: https://gerrit.libreoffice.org/35280
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ief9b377b4352796e19797c397e677e9f8397cc53
|
|
Change-Id: Ic1224311fbab77c7bb21a502dfa4af9506ddfd75
|
|
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
|
|
and drop the trivial subset of it EnumFunc
Change-Id: I9ee7de829121f04e97c167b133cdc78c5ffd0822
|
|
Change-Id: I7d405830785cb12aaceb65d6ed03dda04aa90fd8
|
|
Change-Id: I9a5e937905fd71ecbbf9cb215ff6cc2b7defc6f3
|
|
Change-Id: I946c64d103f3666e5bbff16d95a5c8e65a3750dc
|
|
Change-Id: I9cd92b53370a6b6018d2f7c648890f9c014a27de
|
|
use case is a desire to enable viewing and setting rounded rectangle radiuses
to an exact known value
Change-Id: I7e6a4db0699076950adf5869a61825159766c46a
|
|
Change-Id: Ib4d77ee01e7362f5951f81fceeca3c489872d971
Reviewed-on: https://gerrit.libreoffice.org/17378
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
make it consistent across the codebase, no space between keyword
and the colon
Change-Id: Idca61ddfc74ad2460fb05fe417499324b05e5de5
Reviewed-on: https://gerrit.libreoffice.org/17148
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I92158457b3ffaaf7c84c6f4c87708d766c8c9f61
Reviewed-on: https://gerrit.libreoffice.org/17117
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ib4fb12e187eb4bad7da04425328d1f5cdf851654
|
|
Change-Id: Ie6751bc97914e4b8ac1fe00aae41c02fff2773d9
|
|
Change-Id: I1393240d8ba74388484839fb94bb82fd9d78da32
|
|
Change-Id: I8371b942d915f777a29ca01cd0aed674db0ca853
|
|
Change-Id: I7223530ae37297a76654cd00cc1fedb56dbe3adb
|
|
...in the same vein as 80a1a2599e04142683d2286d0e32d0e13fb45de3.
Change-Id: I5ffb27f0bc965aede03e6d1e849cd68ef6e16e2a
|
|
Change-Id: I2c4eb18e6bf140d37a10c8105922e13583dcde41
|
|
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
|
|
and optimise some methods in bmpmask.hxx - they were unconditionally
returning true, so convert them to void return type.
Change-Id: If8b092a857ab80ead93112b0d627e41d5ccb3cf9
|
|
Change-Id: I2c280be12f36c1538e922286745aabc62482423d
|
|
Patch by: Jianyuan Li
Review by: alg
(cherry picked from commit 462656d2f30fade52e38094dcc2392f75b28ef79)
Conflicts:
svx/inc/svx/EnhancedCustomShape2d.hxx
svx/inc/svx/EnhancedCustomShapeGeometry.hxx
svx/source/customshapes/EnhancedCustomShape2d.cxx
Change-Id: Ifd1fdf1b79db8229b52db43b3c30f109a9930988
|
|
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
|