| Age | Commit message (Collapse) | Author |
|---|
|
This adds the code for undo/redo for change of theme colors in
styles and direct formatting.
Change-Id: I58568b18ab18562e6148ec8530d3d22c62ef2b95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154305
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This adds a Calc specific ThemeColorChanger, which changes the
character and background colors in styles. In addition add the
changes that make this possible - support in SvxBrushItem for
the ComplexColor, making sure that ComplexColor is properly passed
to other items (mainly from color picker),...
Change-Id: Id2e98c42bbe195a0f75cc8951ff69f6d7eea6be0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151667
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Iae8f502a24187f4d41f60fbb727066f214d1cf70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151449
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
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>
|
|
... and use it in one unit test case. Also, remove the code inside
DEBUG_AREA_BROADCASTER macro since it no longer builds & has been
superceded by this new state query method.
Change-Id: I38691a76df5c63034ff488522936dd566bf8b4e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148079
Tested-by: Kohei Yoshida <kohei@libreoffice.org>
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
- These are hard/impossible to implement properly, since they all
use 'SearchCriteria' argument, which is an expression to be matched,
and already strings are hard in opencl and parsing/evaluating/whatever
an expression would be so complex. Maybe number matching or very basic
expressions would be possible, but not much more.
- The opencl implementations of these are (hopefully) very unlikely
to be ever used, since they generally do not make much sense to be used
in formula groups (except if the result is repeated in the group).
As such, simply remove these, as it's just not worth it.
Change-Id: If007c84c1ff684a94cfce0fe171691d9b3578658
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140250
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The default precision of both iostreams and stdio is 6 decimal places.
This means that e.g. =POWER(1.0000001,2) becomes 1, since buf << number
will write that first number simply as '1'.
Moroever some generated code actually doesn't compile because ambiguous
overloads, because '1' is an integer and not a double, thus floor(1)
is ambiguous, as there are only floating point overloads (and C/C++
are stupid about these conversions).
So force using a wrapper class that forces a higher precision and
the decimal separator. For debug builds, also avoid excessive precision.
Apparently, neither iostreams nor stdio are capable of simply printing
a reasonable floating point representation that wouldn't be too precise
or imprecise.
Change-Id: Ifa045712d90e6a6bbe5781ac3c805c989673dc8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139073
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The idea is that there's a cache for a given range, which keeps
a vector of SCROW items, sorted by values of those cells. This
allows some specific cases of e.g. COUNTIF to simply use
BinarySearch() to find the range that matches and work only with
that. This commit implements using this cache for COUNTIF.
Change-Id: I5b36b289b4aecb3b8245bbb447fbb299371262e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134120
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
dociter.cxx/hxx are already quite big as it is, and the query
iterators are more about queries than about iterating the document.
Change-Id: I49e3a5636e4f366efb8b4968f54567d2716ade35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133323
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Having a separate sparkline context is very useful, so we can add
a custom UI when the user has the cursor over a sparkline. This
will allow a "Sparkline" tab for NotebookBar and its own deck in
Sidebar, activated only when the sparkline is present. Also the
pop-up menu can be customized specifically for the sparkline, but
this may be less useful.
For the sparkline context we need a custom shell - SparklineShell
where now all the UNO commands can be implemented (not done in
this commit).
Change-Id: Idca2ad946af3afdd1b494744b80c9c093eec602c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133022
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This adds a "edit sparkline" action to the context menu and a
dialog to change the data range of a sparkline. To change a
sparkline using undo/redo, a new class UndoEditSparkline was
added, which allows to change the attributes of a sparkline and
revert back the old attributes when undoing. This is then used in
the Dialog when setting the changed data range of a sparkline.
To make sure that undo/redo works correctly, a simple unit tests
was added.
Change-Id: I08af1813fa288278bc0d33b0540660b325b17235
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132748
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I309087a27ea0bc297c9bea9b2b8945579e055f4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132552
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This change allows to group parklines together into a sparkline
group, or ungroup them, so they use their own sparkline group.
This also adds the undo and redo for this actions.
Change-Id: I61b604203afaf2fe8c2d47b80082739ded15d6fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132545
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I34e11a4881c564351c3e08d157fb42ac4bb8ef3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132544
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
As SparklineAttributes are COW, we can just exchange them around
in the SparklineGroup when undoing and redoing.
This also changes SparklineDialog to work with a local copy of
SparklineAttributes when editing, or an empty initial copy when
inserting a new Sparkline into the sheet.
Change-Id: I36e9c887ca640f40266f381e98e57f027a5ca07f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132542
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I0d8293cdd35cc8c7afab98efac0a28a3613d122b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132505
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
The attributes can be independent of the actual SparklineGroup,
so they can be shared through multiple SparklineGroups and with
the attributes being COW, they can be safely changed without the
fear that it will impact a different SparklineGroup insstance.
Change-Id: I274b1243d014288ea34a213326ef765ceff86a58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132502
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Adds the code to delete the Sparkline via DocFunc + test.
Change-Id: I710a1ee59a5fe5f2bfb91f8bf487501ef39ce949
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132475
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Move the code to insert a sparkline from the SparklineDialog to
DocFunc and inside the UndoInsertSparkline, so there is no code
duplication and the code can be tested.
Change-Id: I85f4020190ae835b33e706ec9cb2cda9fd6fc752
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132474
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This adds a SparklineDialog, which is used to add/edit the
Sparkline input/output ranges. The command for the context menu
"Insert Sparkline" calls the SparklineDialog for inserting a new
sparkline into cells. Currently the SparklineDialog include the
properties for the SparklineGroup, which will be added in a later
commit.
Change-Id: I9036d788fdf2a035f1ce10fc7413327a92144137
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132465
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
We need to access a list of sparklines and sparkline groups for
a sheet. To preven going through all the columns of a sheet, we
need to store all the created sparklines in a list. For this it
is necessary to change the model structrue a bit. A cell now has
a container that stores a shared_ptr to the sparkline instead of
storing the sparkline directly. With this we can store a list
of weak_ptr to the sparklines in a list (vector), which can be
accessed at any time and is quite fast.
This is needed by the OOXML export.
Change-Id: Iaca0a41e20912775f072ea6e8cab9c44367d6f30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131919
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This adds a Sparkline class and a SparklineGroup class. The
Sparkline class is added to a cell, and the SparklineGroup
is referenced by the Sparkline, so multiple Sparklines can
share the same properties.
Change-Id: Id309ded34bfa7a35c1be43f7c0543d88594e66ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131162
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
It's been a source of numerous problems since the beginning.
Poor separation of C++ code causing the compiler to emit some generic
code as CPU-specific, compiler optimizations moving CPU-specific
code out of #ifdef to unguarded static initialization, etc.
And it doesn't seem to even particularly improve performance,
on my Ryzen2500U for one full column (1m cells) sumArray() takes
about 1.6ms with AVX, 1.9ms with SSE2 and 4.6ms with generic code.
So SSE2 code is perhaps worth it, especially given that SSE2 is our
baseline requirement on x86_64 everywhere and x86 on Windows,
but AVX+ is nowhere near worth the trouble.
So this code removes all AVX+ code from Calc, and makes SSE2
a hardcoded option on where it's guaranteed. If we raise the baseline
to AVX, the SSE2 code may be replaced by the one removed by this
commit. Generic code is there for other platforms, if other platforms
add CPU-specific code, they should preferably follow the same rules.
This does not necessarily mean that CPU-specific code cannot
be used at all. Some externals use them, for example. It just
needs to be working, maintained, and worth the trouble.
Change-Id: I5ab919930df9d0223db68a94bf84947984d313ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129733
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
It turns out svl::SharedStringPool::purge() can be somewhat
expensive with larger documents. Profiling suggests it's primarily
the cost of the CPU trying to access the rtl_uString instances
scattered all over the memory, so it can't be easily optimized.
So instead delay and compress purge() calls if they come from
temporary ScDocument instances from undo or clipboard.
Change-Id: Ie26cce113025ff45ee2c473c6b06f684f453b27b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129713
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This separates the drawinglayer core functionallity into a
separate library, to keep a strict separation what is backend
dependent and what is not. More strict separation can be done
at a later date.
This will make it possible to push part of drawinglayer
(part of processor2d) directly into VCL.
Change-Id: Ibc26580067e50bf20d7cdd37fa0e44eb10200878
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127286
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...instead of by listing the content somewhat redundantly in the Rdb_*.mk
files, to avoid duplication of logic for components that are only built
conditionally (and thus should only be included conditionally in the
corresponding Rdb). To achieve that, add an "rdb" parameter to
gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros
that internally call gb_ComponentTarget_ComponentTarget), which is used to make
the appropriate gb_Rdb_add_component call internally from within
gb_ComponentTarget_ComponentTarget. (As a special case,
gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that
has already been done by the corresponding gb_Library_set_componentfile call, so
allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to
support that special case.)
Most Rdb_*.mk files are thus mostly empty now. One exception is
i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as
needed during the build in CustomTarget_i18npool/localedata.
1c9a40299d328c78c035ca63ccdf22c5c669a03b "gbuild: create services.rdb from built
components" had already tried to do something similar (in addition to other
things) under a new --enable-services-rdb-from-build option. However, that
approach had four drawbacks that this approach here addresses (and which thus
partly reverts 1c9a40299d328c78c035ca63ccdf22c5c669a03b):
1 Rdb_services shall not contain the component files of all libraries that are
built. While that commit filtered out the component files that go into
Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files
that go into others like Rdb_postgresql-sdbc
(connectivity/Rdb_postgresql-sdbc.mk).
2 The code added by that commit to Makefile.gbuild codified the knowledge that
there is an Rdb_services, which is brittle.
3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge
(for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle.
4 Introducing an --enable-services-rdb-from-build option needlessly provided
two different ways how the content of Rdb_services is assembled.
The changes done here would leave --enable-services-rdb-from-build as a
misnomer, as it no longer controls how Rdb_services is assembled. I thus
renamed it to --enable-customtarget-components, as that is apparently what it
still does now.
Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It's somewhat confusing that an accessor is provided to give
a reference to internal data and then the object is modified
indirectly using the reference. It appears to be only for
performance reasons, so I thought that inlining the ctor and
ctor could help the compiler to optimize this, but apparently
it can't move this outside of the loop, so at least make it
clearer.
Change-Id: I72cf15d1446daa559ac4079b9478e53694d7d198
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126394
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This reduces the number of arguments passed around, removed the need
for ValidQueryCache (as the data can be now cached in the class
itself), it'll allow even more optimizations, and it also makes
the by now rather large (almost 1000 lines) helper class a proper
class instead of tons of inline code.
Change-Id: I585cf580b3e7b2d4512aa535176e97c0abfd547a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126367
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Probably additional bits can be removed, but this now passes.
Change-Id: I366bec43cfd6fb02e914c85c711b3b19586d534d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126161
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Jenkins Windows builds occassionally fails with illegal instruction
(https://ci.libreoffice.org/job/gerrit_windows/110191/console).
This seems to be because those AVX etc. files use std::abs(double),
which is really just a fancy inline function calling the real
fabs() or whatever function. And in debug builds inlines do not
get inlined, they get emitted as copies. And since arraysumAVX.cxx
is listed as the first object for Library_sc, apparently the linker
likes to pick up the AVX-compiled inline function as the std::abs()
version to use for Library_sc.
Try to avoid this in two ways:
- move the CPU-specific object files later in the list of library
files
- use plain C headers in those sources, no fancy <cmath>
Change-Id: Ifd14076f79e9fbd7cc4c4a63a9764dff6715e63a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124249
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This part focuses on allowing it on replacing arrayfunctor
By thefault it will try AVX512F (1,17%)
If not available will use AVX (94,77%)
Use of AVX2 (82,28%) has been avoided even if the code could been more compact
Source of hardware statistics: https://store.steampowered.com/hwsurvey
Change-Id: Iae737a565379e82c5f84f3fdee6321ac74f59d40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115675
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I82c1d61b79d6486f20e51a8814b08149765861d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119159
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib724da1f07be9e8f4d0d505f7f2886990cab661f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97022
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
drop ScSimpleRangeList and just use ScRangeList, which saves us a
conversion step.
Then teach ScRangeList to do a simple merge, since we are loading in row
order, and can just check the last few entries.
Then fix a case of optimisation doing the wrong thing in
ScAttrArray::SetPatternAreaImpl where std::vector::reserve repeatedly
resizes the data array and breaks the normal doubling-resizing inside
vector.
On my machine the time goes from 5.4s to 4.8s
Change-Id: I68a2204e0c02b673bbfe8aa0fdbe126e53ddbb41
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96516
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
rework the "menu" to be a treeview using hover selection instead of
a custom set of widgetry, and drop the newly unused custom a11y code
Change-Id: Ie7d9b7875ce00843b3f262882816cebb472bf681
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95223
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The common usage pattern should be having one source file per each
instruction set and then one source file compiled with neutral flags
that dispatches to the relevant code based on runtime checks.
Which means that there can't be any one "correct" flag, otherwise
all files would get compiled e.g. with SSE4.2 but then CPUs capable
only of SSE2 would crash running that code.
Change-Id: I362bf66f672dae4588a48effe3bcd30c34ea75b3
Reviewed-on: https://gerrit.libreoffice.org/84227
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
and compile it with -arch:SSE2 if Windows.
This code however gets called only if cpuid::hasSSE2()
is true, so this does not cause problems with machines
without SSE2 support.
Change-Id: Ice23ac71d4c577b8811b08c74a3ca500a94fdc09
Reviewed-on: https://gerrit.libreoffice.org/80847
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I7b3a22584bb2e4d501f509ffcd80929feed23a4c
Reviewed-on: https://gerrit.libreoffice.org/79360
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Building against libstdc++ effectively always requires -pthread anyway (as
various standard C++ headers require it, see the comment added to
solenv/gbuild/platform/unxgcc.mk), so many explicit uses of -pthread/-lpthread
can be removed.
Doing a (partial) test build on Linux with Clang -stdlib=libc++ suggests that
libc++ indeed doesn't need -pthread as libstdc++ does.
The remaining uses of -pthread/-lpthread are mostly in configure.ac for the
various BSDs (which somebody else might want to clean up now), and related to
external projects. I tried to be careful to remove -pthread/-lpthread from
makefiles only when C++ object files are involved (so -pthread will now be
included on the link command line by default).
Change-Id: I936e082839cb9a434bd273ce5a1f187a4245dfa1
Reviewed-on: https://gerrit.libreoffice.org/71291
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Add Fourier analysis tool to Statistics submenu.
Use FOURIER() formula to do all the work here.
Change-Id: Ifdaa79d8ee367f1c1f5054248e01853ffe4c6823
Reviewed-on: https://gerrit.libreoffice.org/69472
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
... if the double is an out-of-int-range value.
Also catch domain and pole and range errors.
Move this to it's own sc::power() function that can be reused for
example by ScMatrix::PowOp() to be congruent.
Change-Id: I88331e02e6cdfb5e1dcbf81622d3fc7ce4510478
Reviewed-on: https://gerrit.libreoffice.org/65986
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I6d3183cf281363538c603d126660064a205cda5b
Reviewed-on: https://gerrit.libreoffice.org/66058
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I96a3882cd412ea5d993971df7e20b1fd8da73642
Reviewed-on: https://gerrit.libreoffice.org/64283
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
There is mutex protection needed for accessing the same SvtBroadcaster
when calling StartListeningArea(). Also some of the memory management
and caching needed fixing.
Change-Id: Ia57ed85286cf195521719cfd3b320f73a6342bb1
Reviewed-on: https://gerrit.libreoffice.org/61187
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Iaf23b70f303cd05bcf6450fed1246de894285526
Reviewed-on: https://gerrit.libreoffice.org/57447
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: Iee76ed28d0dcd4ee57115ec951a181b2cf8d35fd
Reviewed-on: https://gerrit.libreoffice.org/57239
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: Ib5727912977eb79cdf1f84bf874919beafc693eb
Reviewed-on: https://gerrit.libreoffice.org/56356
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Largely parallel to what we do for Writer.
Yes, there is a fair amount of duplicated code now for the outgoing
("sink") stuff in sw and sc, that should be factored out (to
vbahelper, probably).
Change-Id: I8df4a81c3b9043e8d6b0b206e3c04660205987c7
|
|
no point in having it separate, the code flow is cleaner this way
Change-Id: Ibc04eb4fa0ee6438b84f181a2cbdb6de22872ac5
Reviewed-on: https://gerrit.libreoffice.org/52487
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The current update MSVC 2017.5 supports fancy new C++ features, but
unfortunately in its default C++14 mode it falls over and dies with
an internal compiler error as soon as it sees the WeakImplHelper
variadic template.
In order to work around the ICE, build everything as C++17,
which somehow doesn't crash.
This causes loads of deprecation warnings about obsolete std::this
and badly designed std::that, almost all of them from boost headers,
which are well known for following every best practice in the C++ book.
Liberally sprinkle macros around to suppress the warnings for now,
like we already do with the other million warnings from boost headers.
Change-Id: Ia6b6ef5e457b5fe3c8cfe361ba5da39376bb7c4c
Reviewed-on: https://gerrit.libreoffice.org/48225
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
