Age | Commit message (Collapse) | Author |
|
Added freeze row and column buttons in online UI did not work
because the case for LOK was not handled
Change-Id: I44315c6bc89ae02b7a8ac4c7c493ad7e8eda439e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101127
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Tables can be empty/not populated during import, bail out in such cases.
Change-Id: Idfefdc153215ff5150aa2040858349ed9f0198a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99415
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
to allow an integer parameter as the row/column index of the freeze and
use them to set/get freeze indices (row/column) from the lok clients.
The behaviour of the exisiting freeze/split-panes controls in desktop
Calc is not affected, but new menu/notebookbar options can be added for
freezing on a specific row/column in a follow-up commit.
For now, the freeze-panes are shared between all views for each tab of
the spreadsheet. "Private" freeze-panes support can also be added
without much difficulty (for this we need another uno command for the
private/shared flag, but that can be in a separate commit).
Notes regarding compatibility:
Since Online-Calc has support only for the freeze-panes functionality
presently, any pre-exisiting 'real splits' in the spreadsheet (created
using the native-desktop Calc or alternatives) are converted to
equivalent 'freezes' on import, but on export, such 'freezes' are
re-converted and written as 'real splits'. In case the spreadsheet has
'freezes' on import, they are used/exported as such. In short, the type
of sheet-window splits in the document is preserved.
Change-Id: Ia990616f5cedfb2b5db820770c17ec7e209f0e48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99352
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
as a result LOK_CALLBACK_GRAPHIC(_VIEW)_SELECTION messages will now be
in print-twips.
For tile-rendering, it needs the pixel-aligned coordinates of each
object. The translation of print coordinates to pixel-aligned
coordinates can be done behind the scenes by the
ViewContact/ObjectContact/ViewObjectContact objects associated with the
draw object which uses the cached "grid-offset" for each object
(introduced in the patch "Refactor calc non-linear ViewToDevice
transform"). For doing this, a subclass of FmFormView with a specialized
"createViewSpecificObjectContact" method is used for tile-rendering. The
createViewSpecificObjectContact creates a "proxy" object-contact object
that delegates the grid-offsets queries to the actual ScDrawView
generated ObjectContact. This is needed because currently there is no
way to share the ObjectContact/ViewObjectContact instances between
different SdrPaintWindow's without making changes ~everywhere.
Change-Id: Ifdfb623c8d6dd81700ec4a5dfeeb6b2391a96154
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98166
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Paper size for the EditEngine is calculated based on per-cell pixel
alignment. So lets use the exact print-twips version whenever we need it
to compute/adjust output-area and visible-area of EditView.
Change-Id: I7da6db9363d09965315ff5ca9d01f0fea141a533
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98066
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
The ordering matters at the moment (unfortunately), since
EditView::SetOutputArea(), after updating the output-area it also sends the
LOK messages(cursor/selection) immediately. So we need to update the
print-twips version in EditView by calling SetLOKSpecialOutputArea()
beforehand to avoid wrong messages.
Change-Id: Ibff64ad1a92f332ad726452369ecb2c5b2aaae53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98064
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Change-Id: I0207e65fc0386eb9a86de6ab4472780553eadd4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98062
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Change-Id: Ia2470f98954859b191432d68db5742d13a61c802
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98061
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
whenever EditView::SetOutputArea() and EditView::SetVisArea() are
called.
Change-Id: I90a840b85d01d27427fbaa1101148ce1efb55db5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98060
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
via a optional flag bInPrintTwips (false by default) in
ScViewData::GetEditArea()
Change-Id: I9bf7465b703a2df817fe438db3671261d0d907a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98058
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
when we send the message in print twips coordinates. It is important for
the client to know the exact position and coordinates to allow client
side print-twips -> tile-twips conversion when/if it is needed.
Change-Id: I6699894758886f1b5648ac9bf3c9e6ab4192c72e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97963
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Change-Id: Ie8f23bd7ba8de57d7aab104add99501a54f08819
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97961
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
in case of views with heterogeneous zooms.
1. EditText render position fix
The EditView has an 'output-area' which is used to clip the rectangle
we pass to the Paint() call. It also holds on to the ScGridWindow
instance where the edit started. The 'output-area' of the EditView is in
the coordinates/units of the MapMode of the ScGridWindow it holds. So we
need to temporarily change the MapMode and 'output-area' of the EditView
in agreement to the device(with the current view's zoom settings) where
we are going to paint to. After we call the Paint(), we rollback the
original settings of the EditView.
2. EditViewCursor position fix
Before this change the cursor position in twips (calculated based on
pixel aligned cell position in the view where editing occurred) is
broadcasted to all the client-views. If the clients have different zooms, then
simply scaling this common cursor position in the client for its zoom
is not going to be accurate enough (due to the non-linear Logic->Pixel->Logic
transformation involving pixel rounding). This is very visible if you are
editing far away from A1 (like Z50).
The fix is to turn off this broadcast for calc-cell editing and send
view specific edit-cursor invalidation messages.
This is accompanied by a online.git patch that removes unnessecary
broadcast of view-cursor invalidation messages which messes up things again.
"Do not broadcast view-cursor invalidation messages"
Change-Id: Ib2fbbe4b6f93f26fc85d6adaa8684dd4397d886f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92631
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
(cherry picked from commit d58f1e334245f9e136750fbba267c2a941a213cc)
Conflicts:
editeng/source/editeng/impedit.hxx
|
|
Switching the zoom is no longer necessary - we now have a known
and fixed zoom per view now (as the core has), that saves some
complexity.
Change-Id: I14c952ca1e06fae016faa8b6ee07115c56312ed6
Reviewed-on: https://gerrit.libreoffice.org/84372
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94392
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Doing faster lookups across the calc data structrures is far more
effective than complex caching of this kind.
Change-Id: I43d3ee948ae817ec1d196acc6e5603e6acf1970c
Reviewed-on: https://gerrit.libreoffice.org/84371
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94391
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
we already have a ScTable::GetRowHeightScaled method that uses spans, so use
that.
Change-Id: I126292b4a8b37ebf2d4f737dcbfdadc31226531e
Reviewed-on: https://gerrit.libreoffice.org/82520
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
from https://cgit.freedesktop.org/libreoffice/core/commit/?id=a8a064d11c05feed83f05b0ce8209f7054afd804
See bt: https://bugs.documentfoundation.org/attachment.cgi?id=155761
Change-Id: If527f539e47e3a2ff9f3745665080adc955ea75b
Reviewed-on: https://gerrit.libreoffice.org/82559
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9b706c9bcc2925f72cc024142ffe72af5ddea82a
Reviewed-on: https://gerrit.libreoffice.org/82419
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Do the tile rendering and alignment ourselves. More work required
to get cleaner conversion between view and document twips (view
twips being rounded to produce nice round pixel sizes when
re-converted).
Change-Id: I51edb186cfd2dc434005cc074f4ed8de19c85cb3
Reviewed-on: https://gerrit.libreoffice.org/82092
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
It started out as a wrapper around character literals, but has by now become a
wrapper around arbitrary single characters. Besides updating the documentation,
this change is a mechanical
for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done
Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f
Reviewed-on: https://gerrit.libreoffice.org/80892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The ScViewData is able to not have a document for a time, curious
to allow a model-free view, but there it is.
Change-Id: I402fa5f814f3cc674b733353c5d3fa2de1970e23
Reviewed-on: https://gerrit.libreoffice.org/80631
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I78c4fb4acf21756f91582caee5e30e3ad1fc2ae4
Reviewed-on: https://gerrit.libreoffice.org/79543
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia6e1617ee7f02227bf15277cf25865134dfd1f2a
Reviewed-on: https://gerrit.libreoffice.org/79465
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
To complete this:
https://gerrit.libreoffice.org/#/c/78312/
This is a massive replace for
".." instead of "..." between words.
It passed "make check" on Linux.
Change-Id: I144d8061fca9f545c762941551e59dffdd3650e8
Reviewed-on: https://gerrit.libreoffice.org/78357
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
To complete this:
https://gerrit.libreoffice.org/#/c/78312/
This is a massive replace for lines ending with
".." instead of "..."
It passed "make check" on Linux.
Change-Id: I07fa7b2e30ba9ea17a1f9a5e21c57216ba958efe
Reviewed-on: https://gerrit.libreoffice.org/78356
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I55eca745a84998c74e2d925ed53af20382d98289
|
|
1) Rename Tab
2) Insert Tab
Change-Id: I7a653a4b274c0c8058672c5b0aa1645bb5a51e3a
|
|
It ensures that const begin()/end() methods will be called,
removing any overhead.
fca94779872b8ba0b0583d0b7068f1a46beb88c5 follow-up.
Change-Id: Id680744abb1b3887f25c9bfa033106de18a9c2d0
Reviewed-on: https://gerrit.libreoffice.org/77250
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I3e6b96f4ea341130e98ee54ed8c124209b05d343
Reviewed-on: https://gerrit.libreoffice.org/77291
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ie47dff381392ef57cb857184c179bf82d3b55862
Reviewed-on: https://gerrit.libreoffice.org/77258
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Use range-based loops, STL and comphelper functions
Change-Id: I047fb2e6ec9591166339b9748c5013a32185f14b
Reviewed-on: https://gerrit.libreoffice.org/76912
Tested-by: Jenkins
Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
|
|
Change-Id: I050b4bdff4eaa645316538725c69e83bee4a90c5
Reviewed-on: https://gerrit.libreoffice.org/74526
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
to find stuff like
OUString s = OUString("xxx")
Change-Id: Ie7ed074c1ae012734c67a2a89c564c1900a4ab04
Reviewed-on: https://gerrit.libreoffice.org/70697
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
horizontal / vertical splits
In the tiled rendering case the horizontal / vertical splits were
not implemented, so the leftmost visible column is 0.
So preserve horizontal / vertical splits when saving the document
Change-Id: I15b6f009910e51fdaf475de5aac1ebded16c1956
Reviewed-on: https://gerrit.libreoffice.org/69926
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
Change-Id: I6d678b2969f0e16afe7f7f88e0610175553714b5
Reviewed-on: https://gerrit.libreoffice.org/67651
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Use range-based loop or replace with STL functions
Change-Id: I5604325cd25c099d3b5580956417620f298faa1e
Reviewed-on: https://gerrit.libreoffice.org/65572
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0516dc68cf7d451eafc044be8e50a66d2bddf15f
Reviewed-on: https://gerrit.libreoffice.org/62484
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This disables shading of URL and email address fields when
displaying cell content and still preserves shading in the Input
Line and when editing cell content to indicate that it is actually
a field content value.
Change-Id: I8737045168646b6cd446bd357713ec9ac4631b31
Reviewed-on: https://gerrit.libreoffice.org/61594
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: Ie0fe76ef5c5c706007c2285b3a309d92ff4bc2b0
Reviewed-on: https://gerrit.libreoffice.org/60528
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I152482ef594c286d3c2a94cab62feff49bbf79fa
Reviewed-on: https://gerrit.libreoffice.org/58884
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I71d688862458df25e3f417e7aee32d072aa51d50
|
|
Change-Id: I102c9ea0b11144cc930b5e4d3617f6178b63218b
|
|
Change-Id: Iaf52b7eee0e906d2c21982b354b69fd8d87231e3
|
|
and
coverity#1438221 Argument cannot be negative
coverity#1438213 Argument cannot be negative
coverity#1438227 Argument cannot be negative
coverity#1438223 Argument cannot be negative
coverity#1438222 Argument cannot be negative
coverity#1438215 Improper use of negative value
coverity#1438220 Improper use of negative value
coverity#1438217 Improper use of negative value
Change-Id: I398ae9901b27f6b65f03aad03638939b5880a671
Reviewed-on: https://gerrit.libreoffice.org/58626
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.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 directory sc
Change-Id: I988d7d3abaedfb32516a9db88815663bf54da46e
Reviewed-on: https://gerrit.libreoffice.org/58266
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Idca4bfaaa9f127eae87ae879e2131aed747ce4b3
Reviewed-on: https://gerrit.libreoffice.org/58089
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...by explicitly defaulting the copy/move functions (and, where needed in turn,
also a default ctor) for classes that have a user-declared dtor that does
nothing other than an implicitly-defined one would do, but needs to be user-
declared because it is virtual and potentially serves as a key function to
emit the vtable, or is non-public, etc.; and by removing explicitly user-
provided functions that do the same as their implicitly-defined counterparts,
but may prevent implicitly declared copy functions from being defined as non-
deleted in the future. (Even if such a user-provided function was declared
non-inline in an include file, the apparently-used implicitly-defined copy
functions are already include, so why bother with non-inline functions.)
Change-Id: I4efe3eb088e5f9096be87dd8240504768755112b
Reviewed-on: https://gerrit.libreoffice.org/58096
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I56f6c12525c1be876a4f536c6a07ed3a888600ee
Reviewed-on: https://gerrit.libreoffice.org/57036
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
These were quite a bit entangled with each other
thus a lot of fallout management was necessary.
Also try harder to use fw declarations in files already checked
Change-Id: Ia69c3a0d66ec2763ac03094aaa1b646a290d3cfa
Reviewed-on: https://gerrit.libreoffice.org/56361
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Problem:
users A and B open the same empty document, and the initial document
height is the same for both views, say 100 rows;
user A goes to row 1000 and enters some text
user B is not able to scroll below row 100
Change-Id: I68efe03473c6f82d68182a951034d2e95ffa7765
Reviewed-on: https://gerrit.libreoffice.org/53996
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Marco Cecchetti <mrcekets@gmail.com>
|