Hide the UI to create new documents unless the
experimental editing mode is enabled. There is
little use in creating new empty documents when there
is no way to edit them...
Change-Id: I2f8c86f5db96a5135ff8a66a7a7078b664d05a5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145735
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... and gradle to 7.5.
Change-Id: If5156ab18dc500dafdfa4f8a0f6e6c2563acc4db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145711
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
this is a left over from unused code removal
Change-Id: I6f6451561ae644a41d402f4de0d805a00945a66d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145712
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This is similar to ceea8f3924 (sw:
.uno:TextFormField: add new Wrapper parameter, 2023-01-16), but that was
for fieldmarks & footnotes, while this is for refmarks & footnotes.
Also start a new test file as the one for the entire directory starts to
grow too long.
Change-Id: Ib7c0e03d6686a8a52a5691a4e2dbf97dcc2facba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145698
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Avoids covering of content when zoomed out
Shows the indicatior as a triangle now
Change-Id: Icb613e0e728852dd2dfb6d52ad657a986d0c1a0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145677
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
...which happened to go largely unnoticed (the would-be additional overload, as
seen when including drawinglayer/processor2d/SDPRProcessor2dTools.hxx first
thing in drawinglayer/source/processor2d/SDPRProcessor2dTools.cxx, was just
never defined nor used), but caused
> drawinglayer/source/processor2d/SDPRProcessor2dTools.cxx(140,6): error: externally available entity 'prepareBitmapForDirectRender' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external]
> bool prepareBitmapForDirectRender(
> ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
with clang-cl
Change-Id: I9f338dd998b66fe3223af045206a423b016b93f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145696
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Avoid magic in preTest() based on the bugdoc name.
Change-Id: I40e3d58230e8e815bcea067cfc0ecca4ebeca98e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145683
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
I couldn't find any way in MS Word to escape a double-quote
that is inside of a conditonal text result.
So just "emulate" that with a single-quote,
which is a common substitute at least in the English world.
Hmm, Google says that { QUOTE 34 } would do the trick,
but it didn't work for me in Word 2010.
Change-Id: Ib9833e482911809c86b4e300533ea0aedbeed71c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145685
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Pressing and holding action keys such as arrow keys must not be handled
like pressing and holding a character key as it will insert unexpected
text.
Change-Id: I6beaff265e6cae30337b025791692ff67b760ff8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145689
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@neooffice.org>
DOCX is very much dependent on the true and false text
being in quotes. Likely any inside quotes need to be escaped,
but I haven't looked at that yet.
Change-Id: I9f1976a92ea21d9d444ab2e405a0678daa8f939c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145684
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
If the cursor is still on page one then when a header, via a control on
another page, is added it jumps back to that page, so the widget on the
now hidden page is removed, but the click handler hasn't completed so
the follow up action to change it from a "plus" button to a dropdown
menubutton was on a disposed widget.
Change-Id: I981126412a0ee6a667d77fb97a3db2f2b0a0363c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145665
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
When
- WholeRow/WholeColumn = False
- no row or column matches the FilterFormula
the cells below or at the right were erroneously
shifted down or right.
Future behaviour:
- when nothing to compact,
the initial range is left unchanged
the return value = the initial range
- when all rows/columns are impacted,
the initial range is cleared
the return value = zero-length string
- otherwise
the initial range is compacted
the return value is the compacted range
In either case, the surrounding cells are unchanged.
Change-Id: I27288878dcadeb4ded297b7bb1e6897947ed5e56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145622
Tested-by: Jenkins
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
which is what the old code effectively did
Change-Id: I19b6de0a0015420d1802969064b3338ce6ae1638
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145663
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This is similar to the fieldmark-in-footnote case, but here we need to
make sure that the layout is calculated before the cursor attempts to
jump to the endnote, otherwise the fieldmark will be inserted before the
endnote anchor, not in the endnote body.
The move of StartAction() / EndAction() calls can be done
unconditionally, it's not a problem for the existing footnote case.
Change-Id: I772d27937456978ca6aa01148eff3163d8877208
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145660
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Just past the concrete type down through a couple of layers, rather than
using a generic type and then casting
Change-Id: I7ba6c83463f3db7176b72cb7e764d3659706ae78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145638
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
So far, Android Viewer was using "fit page width"
as minimum zoom level, meaning that it was impossible
to zoom out to see the full page, e.g. when opening
a doc with page size A4 portrait and using
the device in landscape mode.
Change the minimum zoom level to take the page
height into account as well, i.e. adapt the minimum
zoom level to be "fit whole page" to allow doing that.
However, keep applying "fit page width" as
zoom level when double-tapping, by using
the "fit page width" zoom level as new
default zoom level and applying the default
instead of the minimum zoom level on
double-tap.
("Fit page width" is probably more desirable
than "fit whole page" at least when used on small
devices, at least in all cases where
writing is in horizontal direction, so the user
can see the current portion of text and scroll
down to continue reading/writing.)
Use on double-tap is currently the only use for the
default zoom level, the only previous occurence
was effectively unused since
commit 9ab43aebad
Date: Wed Dec 4 17:18:20 2019 +0100
android: Allow zooming for Calc as well
and finally dropped with
Change-Id I702874f1d9161e5cef660bb4c4a0b7864d6e3c09
("android: Drop superfluous ZoomConstraints#mAllow{,DoubleTap}Zoom").
Change-Id: Ica5d8207bc19a81173143fcb5c3747dc89f9fa81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145658
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Both members are always set to true since
commit 9ab43aebad
Date: Wed Dec 4 17:18:20 2019 +0100
android: Allow zooming for Calc as well
, so drop the two now superfluous members and
getters.
Change-Id: I702874f1d9161e5cef660bb4c4a0b7864d6e3c09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145657
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Editing resulted unusably oversized OLE objects. Keep
its original size to fix the UX problem.
Note: lost zoom is still a problem.
See also commit fdf95de18e
"tdf#152991 sd: fix oversized rectangle of edited embedded object"
Change-Id: I6b73d1aea76ea4addc24ff978403893c3cbd3dac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145432
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
