which means we don't have to explicitly handle OOM, and the resulting
code is much cleaner
Change-Id: I958d6678bb2d6878dda9de6bf82c5314f168db17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166855
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Use of auto num(0) together with decltype<num>(1) is overkill,
when the language explicitly specifies these literals to be int.
Also, change static_casts on literals into function-style cast.
And make some comparisong use CPPUNIT_ASSERT_GREATEREQUAL.
Change-Id: I3af7231a997a4611b564b38facd15a3a6bb76cdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166893
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Regression from commit c804c53548 (sw
content control: fix lost properties on copy&paste, 2023-03-10), select
a plain text content control, copy it to the clipboard, quit: assertion
fails during shutdown because the doc's "placeholder text" char style is
still referenced by a client.
What happens here is that the SwContentControl copy ctor copies the
plain text flag, and that flag is only read in SwTextNode::InsertHint(),
so that causes the problem. Note how that code is inconsistent: we avoid
the creation of dummy characters in the copy case, but we still try to
adjust the start/end of the content control attribute in the copy case,
which makes not much sense.
Fix the problem by not adjusting the content control attribute
boundaries in the copy case, since the original intention was to do
thees corrections only at a UI level, during interactive edit.
It's not clear why this inconsistency had an influence on the clients of
the char style, though.
Change-Id: I86b0516464f24fc453dcd97588dafb8afd010a9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166882
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
so "Preloading breakiterator" is on its own line
Change-Id: If2dfb6e9c636346b8b425187c4faab311cf32131
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166589
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit e2cbe31915)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166866
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
In case this flag is active (intended for DOCX files), then don't
automatically mirror the position of drawing objects, just because they
are anchored in an RTL text node.
Change-Id: Ie743d94ecb511d7de89e8e1e8303896370ce58c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166883
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
This patch moves the cell focus rectangle outside the active cell,
relative to the zoom factor
Change-Id: I9df98125d5c0e571af841442d4db8f02d3c05487
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166870
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Since I did this for the range, I might as well
try to entirely remove parseOoxAddress2d.
This allows me to remove parseOoxAddress2d.
No point in having duplicate functions to turn a string
into an ScAddress.
[I assume this was a left-over from when this code
was in /oox and didn't have access to sc methods.]
Earlier patchsets checked that the new method and the old method
returned the same values for all existing unit tests.
Change-Id: Ic45eaf53417b0d8afad7b49959014162549653ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166606
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...by using UnoInOutParam in all cases. Some types whose Embind mappings don't
employ any smart pointers (like any and sequence) would have worked directly
with pointers, but others (like string and type) would have caused Embind errors
at runtime. So consistently use UnoInOutParam in all cases (and generate
bindings for all the used cases in embindmaker).
Change-Id: If26551bf4e99d10748aec1597d6e99f994dfd86e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166854
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Most of the access to the QtClipboardTransferable
mime data happens exclusively on the main thread,
with the solar mutex held.
However, `mimeData()`, called from `QtClipboard::getContents`
didn't ensure that yet, so as Michael Stahl pointed out in [1],
commit 1db5b87fe6
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Feb 13 13:23:17 2024 +0100
tdf#156562 qt: Sync with system clipboard content if necessary
introduced a data race by allowing to set new mime data.
Introduce a new
`QtClipboardTransferable::hasMimeData(const QMimeData* pMimeData)`
that guards access to the mime data with the solar mutext as well
and use that instead, so all access to the `QtClipboardTransferable`
mime data is now guarded by the solar mutex.
Also add an explicit note for the mime data getter/setter in the
`QtTransferable` base class that subclasses allowing to update
mime data are responsible for preventing data races.
[1] https://gerrit.libreoffice.org/c/core/+/166141/comment/fe75f418_40c1b622
Change-Id: I01dbbb0b37a4c6ad06b4d3001ecce8b0260eb32e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166750
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
As Michael Stahl pointed out in [1], there is a data
race on `QtTransferable::m_bProvideUTF16FromOtherEncoding`.
Adjust the code a bit to no longer make use of the
member and drop it.
The QtClipboard case was fine because both methods making
use of the member always run in the main thread with the
SolarMutex held.
For anything else, the `m_pMimeData` doesn't change
don't change, so access to that member doesn't need
to be guarded by a mutex and thus dropping
`QtTransferable::m_bProvideUTF16FromOtherEncoding`
should be sufficient to address that race at least.
(Another one will be addressed separately.)
[1] https://gerrit.libreoffice.org/c/core/+/166140/comment/bc1c9f11_6ad630b7
Change-Id: Iaf2fb460b129493f5627c95b6968aa57da368b4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166749
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
where it was obsoleted by commits 2484de6728
(Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and
fb3c04bd19 (Drop non-const Sequence::operator[]
in internal code 2021-11-05).
Change-Id: I4ccc647bb794515c8c11f8dfd9a26563f4aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166819
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Also, change the default icon theme on macOS to SVG now that SVG icons
support Retina display resolution and the existing PNG icon themes do not.
Change-Id: I8c86c316b0db005661759c132ecf7e8667cf30bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166867
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Tested-by: Jenkins
where it was obsoleted by commits 2484de6728
(Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and
fb3c04bd19 (Drop non-const Sequence::operator[]
in internal code 2021-11-05).
Change-Id: I4f8dc4f430dc49fa29012b8f064094daceb5e1b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166818
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
where it was obsoleted by commits 2484de6728
(Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and
fb3c04bd19 (Drop non-const Sequence::operator[]
in internal code 2021-11-05).
Change-Id: Ia2b60af973183bbe79656e67b5e37d7efa39a308
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166817
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
where it was obsoleted by commits 2484de6728
(Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and
fb3c04bd19 (Drop non-const Sequence::operator[]
in internal code 2021-11-05).
Change-Id: I9467028fd1a7eeafad7f0dd776a91a9a40770b48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166816
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
where it was obsoleted by commits 2484de6728
(Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and
fb3c04bd19 (Drop non-const Sequence::operator[]
in internal code 2021-11-05).
Change-Id: I14e3634d8e8dd294b673dcda4dde13f01c3e5112
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166813
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
The DOCX bugdoc has a circle shape anchored inside an RTL paragraph:
this shows up on the right hand side in Word, but on the left hand side
in Writer.
What happens is that Writer implicitly mirrors draw objects anchored in
RTL paragraphs, while Word doesn't do this.
Start fixing the problem by adding a new layout compatibility flag that
can be used by the DOCX import in the future, to leave the behavior
unchanged for new & existing ODT documents.
An alternative would be to do something similar to the DOC import's
SwWW8ImplReader::MiserableRTLGraphicsHack(), but 1) we don't have the
page margins by the time we import the shape and 2) as its name says, it
doesn't feel like a clean solution, it's better to handle this
difference at a layout level.
Change-Id: I2ec067d86c7fbdbe57e4cd9547015fe25a9a56b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166820
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
In order to indicate the entire row or column
(for the benefit of a spreadsheet program that may eventually
increase the supported number of rows or columns it supports)
a short-handed form of the range can be used
like "B:B" for the entire column,
or "1:10" for the first 10 rows of all columns.
Shorthand is nicer for humans
and allows for future expansion of row/column space
This reverts 24.8 commit a29d91ac40
xlsx export: never export short-hand version of range address
which reduced the likelihood that we will ever see
such a range, because Excel seems to always
write out the full address.
However, the shorthand version is definitely valid for Excel.
Earlier patchsets checked that the new method and the old method
returned the same values for all existing unit tests.
Change-Id: I7677dfc207771a32222095416f728f7cd34a4f75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166570
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
After the change of tdf#139858 the comments checkbox was not remembered anymore after closing the dialog. In order to fix this issue, additionally check not only the NOTE flag but also for the ADDNOTES one.
Change-Id: I8b24d231313b57a05b7e527c0865686762e5a2b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166762
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Tested-by: Jenkins
Using the Double.compare() method is often preferred over the == comparison
operator for comparing double values due to several reasons:
Handling NaN (Not-a-Number) values: The Double.compare() method correctly
handles NaN values, while the == operator does not. If either of the operands
is NaN, the == operator will always return false, regardless of the other
operand. In contrast, Double.compare() will correctly evaluate NaN values
according to the IEEE 754 floating-point standard.
Handling positive and negative zero: The == operator treats positive zero and
negative zero as equal, whereas they are distinct values in IEEE 754
floating-point representation. Double.compare() correctly distinguishes
between positive and negative zero.
Robustness against rounding errors: Floating-point arithmetic can introduce
rounding errors, causing two double values that should be equal to differ
slightly. Directly comparing them with the == operator might yield unexpected
results due to these small differences. Double.compare() allows you to define
a tolerance level if necessary, providing more control over how equality is
determined.
Consistent behavior: The behavior of Double.compare() is consistent and
predictable across different platforms and JVM implementations, as it follows
the IEEE 754 standard. On the other hand, the behavior of the == operator
might vary depending on the platform and compiler optimizations.
Suitability for sorting: Double.compare() returns an integer value that can
be directly used for sorting double values in ascending or descending order.
This makes it convenient for sorting arrays or collections of double values.
Overall, while the == operator might work in some cases, using
Double.compare() provides more robust and predictable behavior, especially
when dealing with floating-point numbers in Java.
Change-Id: I5756936a0d2b4fe11b9113ddd33b6ae691f5103f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166796
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
