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>
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>
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>
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>
might have too much in here seeing as we don't need to worry about
ocWebservice calling into itself
Change-Id: I0145f38cc1c1f9ff514a496f7101d81cde9e7c67
Reviewed-on: https://gerrit.libreoffice.org/47777
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun:⭐:resource::OfficeResourceLoader
com::sun:⭐:resource::XResourceBundleLoader
com::sun:⭐:resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
- Calc: make the complete "what encoding to use" decision before
calling the connectivity driver, so that the driver has
no ambiguity about whether it should override our setting
or not.
To this end, factorise the part of the driver that reads
the encoding from the file header into dbtools.
- Calc: don't ask for encoding when the file's header give the encoding.
- don't confuse CP850 (the default) and "don't know", including:
* don't ignore CP850 user setting
* don't overwrite user setting with CP850
Thanks to Julien Nabet for the extensive collaboration on this.
Change-Id: Id80b7c505858b88f717b0ce6bd890527909e5fd1
It's disabled for now. We need to first make the edit engine and
a few other places thread-safe before we can parallelize this code.
Change-Id: Ie09536964ece42d43f505afc5e2611d469cc5c95
Reviewed-on: https://gerrit.libreoffice.org/38424
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
This reduces the total time required for populating the pivot cache
by ~60%.
Change-Id: I6a8511959c20231a8a5dbd0b0a9a3d0930a1fa0c
Reviewed-on: https://gerrit.libreoffice.org/37971
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Uwinapi is discontinued.
Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01
Reviewed-on: https://gerrit.libreoffice.org/23198
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
This is a squashed commit of the pivot chart implementation.
Some of the changes:
- Add pivot chart specific (pivot table) data provider which
provides the data from a pivot table to the associated chart.
- When inserting a chart and the cursor is in a pivot table,
in that case insert a pivot chart
- Modify the pivot chart when the pivot table changes
- Collect and set the number format for the values
- isDataFromSpreadsheet check for the creation wizard
- In ChartView (and VLegend) check if the data provider is a
pivot chart data provider and get the pivot table field names
to create the buttons on the UI.
- Adds the functionallity to show a filter pop-up (from calc)
when clicking on row / column / page field buttons.
- Remove (X)PopupRequest as we won't need it.
- Add ODF import/export for pivot charts:
+ Added loext:data-pilot-source attribute on chart:chart
which is the internal name of the pivot table with which the
pivot chart is associated with. If the element is present, then
the it means the chart is a pivot chart, else it is a normal
chart
+ Added service to create pivot chart data provider through UNO
+ Add new methods to XPivotChartDataProvider to create value and
label data sequences separately from the data source, which is
needed for pivot chart import
+ When importing defer setting the data provider until a later
time when we know if we are creating a chart od a pivot chart
- Pivot chart ODF round-trip test
- Add table pivot chart supplier API:
This adds the XTablePivotChartSupplier and related interfaces so
we can access, create, delete pivot charts from UNO in a sheet
document. With this we now distinguish between normal charts
and pivot charts. This was mainly needed because we can't extend
the "published" interfaces of TableChartSupplier.
- Added an extensive test, which uses the API to create a new
pivot chart when there was none, and checks that the pivot chart
updates when the pivot table updates.
Change-Id: Ia9ed96fd6b1d342e61c2f7f9fa33a5e03dda21af
Reviewed-on: https://gerrit.libreoffice.org/36023
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
DataProvider class serves as an abstraction of various External
Data Importing Techniques we have and the others which
could be implemented in the future.
Change-Id: I9fc9455f7fbf9025aace4c3248df9b32f522ce52
Reviewed-on: https://gerrit.libreoffice.org/30906
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jaskaran singh <jvsg1303@gmail.com>
get rid of the roundabout way that these popups are popup controllers
(of a kind) for real popups
for the moment keeping them as loaded from resources
Change-Id: I083e8609ab133e3dc4a036daf8bfb44c08a6719f
The xml based transfer of information was a bad idea from the start. It
can obviously not transport the temporary conditional format information
from the manager dialog. Therefore the whole handling here was
completely broken and deleted formats came back, changed formats were
not saved and added formats got applied directly to the document.
Now the document fornat list and the one from the manager are indepedent
again and as long as the manager has not been closed with ok nothing is
written to the document.
Change-Id: I9802be11cd15c2d2d877e55c91d836735fe0e0ff
Reviewed-on: https://gerrit.libreoffice.org/28995
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Insert options during MergeCells to empty hidden cells
Three options:
- Move contents to first cell (previous Yes)
- Keep contents in covered cells (previous No, default)
- Empty covered cells (new option)
To be done: link to the help system
https://gerrit.libreoffice.org/27467/
Change-Id: I98e85296591cce8ba789d282cead1f1010e5e2ce
Reviewed-on: https://gerrit.libreoffice.org/27463
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Laurent BP <laurent.balland-poirier@laposte.net>
For consistency with what 38cd1d9a5f "clew: move
this foreign code to external/clew" did for clew.c. Library_scfilt depends on
clew/clew.h, simply make it depend on the full clew external.
Change-Id: Idcbf56a69084e108832c8970507ebea0f7ff400b
Reviewed-on: https://gerrit.libreoffice.org/24035
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Made the container for storing multimarks dynamic.
Also let the full row marks to be stored in a dedicated
ScMarkArray object rather than in the multimarks container.
Unit tests for ScMarkData and ScMultiSel will come in a follow up
patch.
Change-Id: I300ff80bebd6f4f39c284c1e8cb7deece82c1bec
Reviewed-on: https://gerrit.libreoffice.org/22163
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
In this patch dynamic column structure is introduced,
basically wrapping std::vector<ScColumn*>.
In ScTable the column container is pre-allocated with
MAXCOL + 1 columns so that the rest of the code that uses
need not change for now. So for now the new column
container will still behave like the static one.
The plan is to *incrementally* modify all instances of
iterations over columns to make use of the dynamic column
container and also to address the issues mentioned in the
thread :
http://nabble.documentfoundation.org/tdf-50916-Calc-Dynamic-column-container-td4162663.html
The final step would be to remove the pre-allocation of the container
in ScTable constructor and increase of MAXCOLCOUNT
Change-Id: I3ff18cdebc99d8348e06a76f287d1d30279366bd
Reviewed-on: https://gerrit.libreoffice.org/21620
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Jenkins <ci@libreoffice.org>
8d1a24dae0 "Make virtual ~ScValidationDlg
non-inline" caused the RTTI for ScValidationDlg to only be emitted in library
scui instead of (weakly) wherever needed. That causes UBSan to fail when it
uses the RTTI in ScValidityRefChildWin::ScValidityRefChildWin
(sc/source/ui/view/reffact.cxx, in library sc, to check that operations on
VclPtr<ScValidationDlg> pDlg indeed operate on an ScValidationDlg object).
The cleanest fix appears to be to move ScValidationDlg from scui to sc. As
Moggi put it on IRC, "that dialog should be in sc as it is a modeless dialog; no
idea why it works for that dialog but all other modeless calc dialogs have to be
in sc to avoid linker problems."
One remaining question is whether it is save nowadays in ScCellShell::ExecuteDB
(sc/source/ui/view/cellsh2.cxx) to clean up the ScValidationDlg pointed to by
pDlg when that VclPtr<ScValidationDlg> variable goes out of scope, instead of
doing the PostUserEvent(... DelayDeleteAbstractDialog) dance that was there
before because "after end execute from !IsModalInputMode, it is safer to delay
deleting." Lets see.
Change-Id: I3ecfd4fafc7b37b2f30e75974ece9b0a23311ef4
