... data descriptor; only allow it for encrypted ODF entries, which
requires reading the manifest first.
Change-Id: If36d31a4cb93e7af78f48be3ed899ad9d9bb28f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171911
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Using Navigator
Adds word count information of headings outline content to the
headings content tooltip.
Change-Id: I31163d95139cdc1ef770591684e9cb585ed49a8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171920
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
I know NOTHING about the intricacies of Undo/Redo.
However, this is my feeble attempt to add some sanity to it.
It should not be the responsibility of the caller
to know when they are allowed to call ClearRedo.
This patch reverts commit 0cd000bb83
author Daniel Arato (NISZ) on Mon May 10 15:41:28 2021 +0200
tdf#141613 sw: avoid possible crash when undoing header creation
which was not a sufficient hack.
I hope this patch lays a better framework
to handle future similar issues.
vvv NAIVE OPTIMIST ALERT vvv
mbDoing was added with
commit 9cb53122e9
Author: Frank Schoenheit on Fri Oct 22 15:00:39 2010 +0200
undoapi: more I/SfxUndoManager changes
in preparation of new Undo API features
and has been untouched since then AFAICS,
and there was never any mechanism to change mbDoing.
In other words, it has been sitting there doing NOTHING.
So, I am taking it over and using it how I imagine it was intended,
and how it is documented.
Change-Id: I7aa355cc6458ac8ba34ddb9ee73fc850dcbca702
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170793
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Previously, the Asian Phonetic Guide dialog could scramble base text
during editing due to incorrect handling of PaM after calling
ReplaceRange(). This issue has been fixed. The implementation has also
been modified to allow base text deletion.
Change-Id: I43350272359c7984459aea1604dae0d3f6428cac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171934
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
so we dont keep creating it again. Shaves 3% off the load time.
Change-Id: Id67927f854d55769f76e56c6bc9a9e9bb05eea6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171919
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
it never actually uses the superclass value. It has been this way since
initial import.
Change-Id: I99708c3ad8f1f2727ef87af56c62165d55f348d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171904
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The DBus based session/sreenlock inhibition work on Wayland
just fine, and in a quick test with the qt6 VCL plugin on
Plasma 5 Wayland on Debian testing, the screen saver is
inhibited as expected and doesn't start while an Impress
presentation is running.
The code in `QtFrame::StartPresentation` being
guarded by a `CHECK_ANY_QT_USING_X11` at first
looks like this was all X11-only code.
It already worked just fine on Wayland before
that commit however, as it's a build time check only,
and X11 is enabled by default at build time,
and the code would run just fine on Wayland then
with a null X11 Display.
Drop the `CHECK_ANY_QT_USING_X11` (build-time)
condition altogether, now that `USING_X11` is no more
required after
Change-Id: Ic46c3f18151340a5ea6c0b62a82c957fd1cd6484
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Aug 15 10:13:27 2024 +0200
vcl: Allow DBus-based session inhibition without requiring X11
Move the X11-specific code into the `#if CHECK_QT5_USING_X11` block
and call the overload that doesn't require an X11 Display otherwise.
Change-Id: Idee0564d136e59ce54945670dee26df0cfc64d85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171896
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
So far, building `SessionManagerInhibitor` code was
conditional on `USING_X11`.
Besides direct X11 API calls, it uses DBus calls to inhibit
lockscreen, power management, etc.
The DBus based ways don't depend on X11 at all.
Therefore, build the `SessionManagerInhibitor`code on
relevant platforms unless the GUI feature is disabled
altogether, and make only the X11 specific code conditional
on `USING_X11` in addition.
Move the non-X11 specific code from the existing
`SessionManagerInhibitor::inhibit` to a new overloaded
version that doesn't require an (X11) `Display` param.
This builds successfully in an
`--enable-gui --without-x` build.
Change-Id: Ic46c3f18151340a5ea6c0b62a82c957fd1cd6484
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171895
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The code in this block is X11-specific, so
make it conditional on `USING_X11`, not
`HAVE_FEATURE_UI`.
This fixes an `--enable-gui --without-x` build
that previously failed like this
ld.lld: error: undefined symbol: XineramaQueryScreens
>>> referenced by splashx.c:441 (desktop/unx/source/splashx.c:441)
>>> .../libreoffice/workdir/CObject/desktop/unx/source/splashx.o:(splash_init_display)
[AIN] draw_brand
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [.../libreoffice/desktop/Executable_oosplash.mk:10: .../libreoffice/instdir/program/oosplash] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:296: build] Error 2
Change-Id: If02395d2461de4b6aac340898ce99583653d45c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171894
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This was added in:
commit 6857013101
Author: Andrzej Hunt <andrzej@ahunt.org>
Date: Tue Oct 20 17:24:44 2015 +0200
Add org.mate.SessionManager support
This is valid for Mate <= 1.10
(As of writing, 1.10 is the current stable release - so we'll have
to keep shipping this for quite a few years to come.)
Change-Id: I4d1f81c50923148e710eac22f5428b2a1c41f0e9
As the commit message and code comments say, MATE >= 1.12
also uses the "org.gnome.SessionManager" interface (which is still
supported), so drop the "org.mate.SessionManager" one only needed
for older versions.
MATE 1.12 was released on 2015-11-05, which is long enough ago
by now.
[1] https://mate-desktop.org/blog/2015-11-05-mate-1-12-released/
Change-Id: I062261c6396b35be1a0f452826f8ee2c545f4906
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171893
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When we load complex documents we end up with very large
amounts of SwNodeIndex objects, and we also need call
RemoveNode often, which means we end up scanning tons of objects.
So move the linked list from SwNodes to SwNode, so we can
scan just the objects that we are interested in.
Shaves 10% off the load time of a complex docx file.
Change-Id: Id62388dbc7e41fae30acb7910a982710c80e563e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171888
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
now when a conditional format entry is edited,
instead of editing entry in the same format,
we delete entry from the origianal format and create
a new format with modified entry alone.
This way it easier to manage formats, and it also aligns
with implementation of how format manager adds new
format condition(it adds new format for each condition instead
of adding new entry to existing format)
Change-Id: Iaa92292ca67eaf90374d2af44d2402f9ebe29787
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169537
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170915
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Comments needed to be made compliant with code
in relation to Calc sheet limits.
Change-Id: I67962540e484ab1d51bc79f8ee7e7a73f9f25a2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171872
Tested-by: Jenkins
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
...to be used by external code, to mitigate the issue mentioned in the commit
message of cccc983eb3 "Emscripten: Run external
code on LO's main thread": "Alternatively, running external code on the
browser's main thread rather than on LO's main thread could be more ideal in the
sense that the external code would then have access to the browser's document
object."
On the browser main thread, external JS code can now await a Module.uno_main
Promise that provides one port of a MessageChannel. And on the LO main thread,
external JS code has access to the other port of that MessageChannel as
Module.uno_mainPort. (And the external code is completely free in what
onmessage handlers to set up and what form of postMessage calls to use on those
two MessagePorts.)
Change-Id: Iab6bc7676c744eacb70ddd9f3f80f64e9efd1cf1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171907
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
testPDFAddVisibleSignature was failing for me locally because of
an expired certificate present in my store.
Change-Id: I03243f6707b1b5ca94ea87e9f8c809dd47b6a93a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171901
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
It helped me to easily see which unit test failed, when working on
another change, instead of seeing a segfault
Change-Id: Id0345f508eac3c60265cd62b8aa20d895c3a1d01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171897
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
which shaves some time off loading complex files.
Note that this class is often used as a superclass, so I checked all of
the subclasses and marked some of them as "does not support hashing"
until they can be independently verified to be safe
Change-Id: Id4187eda8d6145e89e17dc10c2e3113b7a93da85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171891
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which simplifies the hierarhcy.
We never allocate such a thing, we always allocate subclasses, and it
has no real meaning by itself.
Change-Id: Ie6b716c9ea6ca0efe0ae4f39ac345608c45534f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In the ODF import, when importing a table, initially a placeholder 1x1
table is created. When this is done from SwView::InsertMedium, frames
are created for the table and its single cell at that stage. Then the
actual table nodes are created, but frames are not created in parallel,
until the table import is finished.
Importing a text box, it used to be created anchored at the end of the
document, and then the anchor was moved to the correct place.
When a text box was anchored to a cell, the process was like this: the
text content was inserted in the last paragraph outside of the current
table; and then it was moved to the current cell. When this was done
from SwView::InsertMedium, creation of the text content also created
the frame; then the movement fired client notifications, including the
SwFlyAtContentFrame::SwClientNotify, which needs the new anchor frame.
With cell other than A1, there was no frames for the new anchor in the
table, and that crashed.
This change inserts the text content into the correct place from start,
which avoids the need to move the anchor later.
Co-authored-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I9dd3a2c5527f3c2dd860244456c617558943453a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171898
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Open the 300 pages bugdoc, paste a oneliner plain text content in a
paragraph which is part of a numbered list, observe a 274 ms hang till
layout is done for all pages, then we get an updated tile.
We already do the layout in two passes: once for the visible area and
then an idle pass for the rest of the pages. But we didn't notice that
the LOK client has pending input events, so the list of events were like
this:
debug:20492:20486: SwTransferable::PasteData: finished in 5 ms
debug:20492:20486: SwLayAction::InternalAction: finished in 273 ms
debug:20492:20486: SwViewShell::PaintTile
With this patch, the order of evens is rather like:
debug:7541:7535: SwTransferable::PasteData: finished in 4 ms
debug:7541:7535: SwViewShell::PaintTile
debug:7541:7535: SwLayAction::InternalAction: finished in 261 ms
Which means that once a LOK client opts in to provide an any input
callback, the end-to-end time from the paste uno command dispatch to
receiving the first tile update decreases from 963 ms to 14 ms.
Change-Id: Ia9e734f84121b7d87150cb3479fc265ca8ee0292
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171885
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Drop external/pdfium/annot.patch.1, it has been upstreamed as
<https://pdfium-review.googlesource.com/c/pdfium/+/120750>.
Update PDFiumPageObjectImpl::getFontName() to match
<https://pdfium-review.googlesource.com/c/pdfium/+/121911> "Rename
FPDFFont_GetFontName() to FPDFFont_GetFamilyName()".
Extend external/pdfium/build.patch.1 to work around:
> C:/cygwin/home/tdf/jenkins/workspace/gerrit_windows/workdir/UnpackedTarball/pdfium/fpdfsdk/fpdf_annot.cpp(1083): fatal error C1001: Internal compiler error.
Change-Id: I94ed21265a79d484759f240f3baeb51c92365c78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171884
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
In Online, we previously weren't able to specify what we wanted the
theme to be after an invert. This led to the theme being "whatever the
*last* person toggled it to" rather than "whatever isn't our current
theme"
This commit also lays the groundwork for loading the same invert theme
after a reload/rejoin/new doc in Online
There is a change to online to support this here:
https://github.com/CollaboraOnline/online/pull/9652
Change-Id: I05486860c5f562c3cfa59b4a7fc492d48913a181
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171889
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
I DON'T KNOW IF I REALLY WANT TO SUBMIT THIS PATCH.
I'VE ALREADY DECIDED IT IS BEST TO CHANGE THE IMPORT
TO MATCH REALITY, AND KILLING layoutInCell
CERTAINLY DOES THAT.
The Ok button on the UI is the real convincer...
although one unit test had beneficial side effects.
It is very tempting to turn off "layoutInCell".
After all, MSO has rather bizarre exceptions to the rule,
and the whole concept in general is competely unnecessary
(except to fix their horrible initial implementations).
But by discarding layoutInCell,
we are going in the opposite direction
of Microsoft, who in compat15 (2013+),
treats layoutInCell as true
regardless of whether it is set to on or off.
However, there still is one downside to preserving layoutInCell.
In LO's UI, when looking at the properties,
it will change the values to enforce layoutInCell,
so pressing OK will shift an outlying shape.
shape - FRAME/FRAME
-fdo68607.docx [same]
-test_segfault_while_save.docx [zOrder is fixed somehow]
-layout-in-cell-wrapnone-column.docx [same]
make CppunitTest_sw_writerfilter_dmapper \
CPPUNIT_TEST_NAME=testLayoutInCellWrapnoneColumn
Change-Id: I6d66cb2f14507847e346443d42879a60025bc9d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171437
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Turns out the approach implemented in 058f1d1b52
doesn't work out when a smaller tab page is activated at first,
since only the first tab page will define the dialog size.
Change-Id: I1201a0e9174c842d4c023e8438763d6d538d3036
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171755
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
This change fixes an issue presenting as incorrectly-positioned kashida
glyphs overlapping Arabic text after certain edit operations.
During layout with kashida justification, Writer builds a table of lines
that require fallback to whitespace justification. Normally, this table
is built sequentially from the first line, but it may be updated
out-of-order following certain edit operations.
Due to an off-by-one error, if Writer cleared the exclusion for a line
immediately before a legitimately-excluded line, Writer would also clear
the legitimate exclusion. In such a situation, portions of excluded text
would be redrawn with kashida justification, and because that text
usually does not have enough free space, the kashida glyphs would be
drawn on top of the base text.
Change-Id: I204661286531fa6064f7a6adc35f1606e35e5d39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171878
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
