Age | Commit message (Collapse) | Author |
|
Change-Id: I042b8dcadbf7581de325c161763fe35aecde5ca2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133694
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I22e66f3cb370c53e1c5ca1e5fa6760d152def374
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133696
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I95cfb74efd5e28e048c8057a464a57c88aab7e7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133634
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
mostly boilerplate code
jsdialog changes:
- added force parameter to sendAction
- added support for key press/release and command events
- moved ActionDataMap to jsdialog namespace for sharing
formulabar changes:
- added calls to send jsdialog messages with formula
- added cursor moving support - on command event
Change-Id: I714715133901941ba0758655e2d5907a3bae79f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133010
Reviewed-by: Mert Tumer <mert.tumer@collabora.com>
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133652
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
thanks to that we can reach them using LOK as formulabar
is not fully welded yet
Change-Id: Icc1963ab11c1e6e3c407222d76b2a87fdaffa652
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133496
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mert Tumer <mert.tumer@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133655
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
found by examining uses of OUString::copy() for likely places
Change-Id: I6ff20e7b273ad6005410b82719183c1122f8c018
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133617
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which is more obvious, from the perspective of the caller, and lets us
avoid creating a new String if nothing needs to be stripped
Change-Id: I66a980eaf4aa818251bec49bdb16c2dddb0745e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133657
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
- do not block painting
- use welded wrappers to send JSON
- don't send tunneled dialog
Change-Id: I54c3cd02ab63bad4a50a3623a32f13b0c94a3595
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132757
Reviewed-by: Mert Tumer <mert.tumer@collabora.com>
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133651
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
In Move/copy sheet UI, change label
according to selected action
update: with UI test
Change-Id: I8244b1635f56574c7641191be7e15ee4a098dce9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133364
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
Change-Id: I4462f7cf4740fa4d1b129d76a0775f4250f41bbd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133555
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
There might be a more general place where this belongs,
to cover other similar kinds of situations.
However, putting it here is very targetted,
and shouldn't get me into unanticipated trouble.
Any changes made in the "top view" need to be accepted before
they are committed. In this case, the user switched gears
and added a new sheet while in the process of editing.
So what should happen here? Should we commit the change
before changing task? Perhaps. Certainly it should
NOT show up on the new sheet - but that is what was happening.
Accepting the change when the user gets side-tracked is the norm
in cases like print-preview, switching to another soffice app,
or simply clicking on a different cell or switching tabs.
So auto-accepting in this situation is consistent behaviour.
Change-Id: I4f3f0103ad4fcc1aa8a0c6118383b63ace07ff5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126501
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Idfcf34a0101158f54bd73efc8629ea8e660a3b11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133539
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Columns should be dynamically allocated on demand, so there should
be theoretically no good reason to allocate 64 initially. In practice
doing so hides all places that do not allocate columns as needed.
Change-Id: I8b46ecc97852ed23369e720f50f3266c48440435
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133311
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
UITest_calc_tests' columns.CalcColumns.test_column_hide_show fails
with INITIALCOLCOUNT being 1 because column C was hidden, but
searching only up to the first allocated column + 1 searched only
up to column B. Whether an entire column is hidden is not part
of ScColumn, it's stored in ScTable.
Change-Id: Ib1befe5cd0db8d50a6196bc6621fb1b0967e6209
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133524
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I15ca12f35a66994cb90a0ccf60a1ce0f8efcfecc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133459
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I114bec72cb933238675e539a8388a607226827cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133455
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I58fb024fa4e2633999f6be708da830ca3f9833c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133472
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I07f11bf12fbe1d1c2d812fa0965d6e632e1e1aba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133437
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4580d4cce8a53f2b1faf0738d08509d2730868df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133431
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic057769718790ced80daf24510d27aad49e3341b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132975
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: Ia1f1bb31e077dcb4293c1106ac324a25a975a656
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133064
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
...by annotating occurrences of false warnings with [-loplugin:<name>] comments
in source files and letting individual plugins opt-in to watch out for such
suppression annotations, rather than maintaining lists of excluded source files
in the individual plugins. (See the new loplugin::Plugin::suppressWarningsAt.)
Instead of making all calls to loplugin::Plugin::report check for suppression
annotations, the intent is that this check will only be added opt-in to those
places in the plugins that are prone to emitting false warnings. In general it
is better to have plugins that don't produce false warnings in the first place,
or at least let those warnings be addressed with trivial and harmless source
code modifications, avoiding the need for any suppression mechanism.
As a proof of concept, I have removed the exclude list from
loplugin:redundantfcast and instead annotated the relevant source code. (And
thereby found that three of the six originally excluded files didn't need to be
excluded any more at all?)
For now, this mechanism looks for comments (both //... and /*...*/, even
documentation-style /**...*/) that overlap the current and/or the preceding
line, because at least for code controlled by clang-format it is often easier to
move comments to a line of their own, preceding the commented code. Looking
also at the current line (and not only at the preceding one) opens the door for
erroneous over-eager annotation, where an annotation that was meant to address a
false warning on the current line would also silence a potentially true warning
on the following line. This probably doesn't cause much trouble in practice,
but is up for potential change.
Change-Id: I91ce7a0e5248886a60b471b1a153867f16bb5cea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133365
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3584042d0341d5c1b4f4e742e25e9eb0aa26f1da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133378
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
d468958331f36310d11265ba55d7c27366ab58ab improved COUNTIF performance
by copy&pasting the generic query iterator and then basically removing
what was not necessary. Which is in general a good way to improve
the performance, except for the copy&paste part, as the code has
already started to diverge (e.g. fc3b904b671a71266db2e8b30cbeeef4f79).
So instead make the shared code into a template and reuse that from
specific code. This has exactly the same performance as the copy&paste
way.
Change-Id: I168319a1f4273bafc8c0742a114dafbf433968bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133324
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>
|
|
If there's a document with a huge formula group, InterpretDirtyCells()
on load will only interpret the range needed for drawing. But then
scrolling just a bit could result in e.g. IsValue() call on a cell,
and that could result in unrestricted Interpret() on the whole
huge formula group, which could be slow. So explicitly interpret
just the drawn cells in the hope that it'll avoid any further
Interpret() calls.
Change-Id: I01c9f95cf8a1cf240b798feef27d21010957030c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133306
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
ScColumn::InterpretDirtyCells() already takes a row range, and Interpret()
can take a range inside a formula group, so don't lose the information
in DirtyCellInterpreter, otherwise a whole large formula could be
interpreted when just a subset would be enough.
Change-Id: I93e5a7a212976be6fd588de6f68204cd1a271348
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133305
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
First of all, it's very obvious that a return statement returns,
so there's little point in commenting that. Second, 'over' and 'out'
together is Hollywood nonsense, 'over' means "talk, I'm listening"
and 'out' means "I'm not listening anymore" ... so 'over and out'
I guess means "talk, I'm not listening" ?
Change-Id: I60a202c78b33bd063c40ef4cd51514f7a2e6c95d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133321
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The function has been there since the initial commit and is not
documented, but I think it counts the shortest amount of empty
cells in the given area starting from the direction given. And
AFAICT the off-by-one error was there since the initial commit,
when it returned one less if the entire area was empty and
the direction was vertical (horizontal was fine). And
ScHTMLExport::FillGraphList() even was adjusted for this until
my recent commit changing that code). But then ad2bc869bfe2d34bde
added a shortcut for unallocated columns that didn't have
the error. And the error even got corrected during the rewrite
in c008dc483f8c6840803983e7e351cec6fdd32070, but then
01de94471c20a8b9c36d6080638d70e57eac55bf reverted that. Anyway,
so fix this, I think all the relevant code should(?) now work
properly.
Change-Id: I194691f7276a1cea75945de05cb0dda2cdca859a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133319
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The GetEmptyLinesInBlock() call has unclear semantics and it appears
that it has an off-by-one error. Use a simple clear function
for the check.
Change-Id: I45d9b73428aedababc1ad93c202daa1de945b5bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133303
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ie02b6be79d1be7481ebcfbc6862295a34e38f7db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133304
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I4e10945f32dfb535663ea7392f19532e45ca9ee3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133301
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ic58a896a7a2edf5ba602ab9cfc5a4578fd5d0a56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133296
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The problem with GetColumnsRange() was that it was clamping the range
to the number of allocated columns, but that's not always wanted,
e.g. ScDocument::InsertMatrixFormula() needs to iterate over the whole
range and allocate columns if necessary instead of ignoring them.
From an API point of view it's also not very obvious that something
called GetColumnsRange() actually does something more than just
returning the given range.
Handle this by making GetColumnsRange() return the actual given range,
and add GetWriteableColumnsRange() and GetAllocatedColumnsRange()
for the specific cases. This also required changing ScColumnsRange
to work simply on SCCOL value instead of using std::vector iterator
(since the vector may not have all the elements in the range).
Change-Id: I9b645459461efe6b282e8ac5d7a29549830f46c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133295
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I2991ef99f5a617e36cfbe9499ef1c4195d52fdf6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133254
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I274d5b0c8aae2c4313ca8dd724898238c72539ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133253
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Follow-up to bfc43aad0e8eb90e9d3495b940bc2283081f04c6
Change-Id: I0b4562e8a41377839e78c5e471f36eed0a52d5bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133216
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Inserting a hyperlink through the hyperlink dialog should replace the
content of the entire cell if it contains a formula.
Change-Id: I2e06f134bfcd21ec3fef76f2a9b80e433adce1f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132785
Tested-by: Jenkins
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Change-Id: I336fd329b577b6fa141265d8bc7ce67784bd7306
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133210
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8a8ad5456fea349a45fca0aa468313cb04aa02f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133198
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... that can be string_view
Change-Id: I0ddf66725e08b58e866a764f57200dd188b9f639
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133066
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
cache some intermediate stuff that it does a handful of times when
finishing a chart - halves the time taken
Change-Id: I75c5621844d4309b64e64219a7c9e2bcd344ce36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133173
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I853cda76522ebf3c9a8f7389d5b2b6fc9611f502
Signed-off-by: Hannah Meeks <hmeeks4135@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133136
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: I5f77167ad874200fa4f7bc16e5de8a3348cb1886
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133097
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
- remove special type "autofilter"
- now autofilter will be handled by dialog code in online
Change-Id: I3478c3e05ab2e83030a8d68632d0426a5cc0accd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132539
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mert Tumer <mert.tumer@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132916
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-by: Szymon Kłos <szymon.klos@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>
|
|
Change-Id: Iab8b9a802ebac60b52007754430352d3de925374
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133026
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I31193783231f27494ed1507faa143697e8facc30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132977
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4a589f68fcdaa1c62ac08bd6075071d0fed0b28b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132538
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mert Tumer <mert.tumer@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132915
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
for which we have o3tl:: equivalents
Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|