Row/column highlight shouldn't be updated using ScGridWindow::DrawContent
because it would call for highlight refresh even when typing in a cell,
leading to the text being hidden under the highlight.
Change-Id: Ic7cc71bc94629c71e6efdf677b7f34d6c4d0cc93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159636
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Due to the paradigm item change the test
make CppunitTest_sc_tablesheetobj
with CPPUNIT_TEST_NAME
sc_apitest::ScTableSheetObj::testSheetCellRangeProperties
got much slower. Unfortunately it did not break, so got unnoted.
I took a look now. First I intended to add some hashing in an
std::unordered_set using that hash values at ScPatternAttr, but
that is not even possible due to other data in that item that needs
to be compared. I had the impression that it was 'somehow' hashed
before, but after debugging the version before that change I
noted that also the list of existing items was linearly compared
to the new entry, using the operator==.
Thus the problem was not due to not hashing, but due to the
ScPatternAttr::operator==. That uses the hash (not changed),
but no longer finds equal entries.
This is because the hash code is made up from the SfxPoolItemPtrs
in the SfxItemSet, so when all are equal we can be sure the SfxItemSet
content is equal.
To use this the other way around is *not* correct: Even with
not all ptrs equal the SfxItemSets can still be equal, simply
by one SfxItemSet using another, but identical incarnation of
an item. Thuis means that ScPatternAttr::operator== does not
detect all cases of equality.
This worked in most cases before since most items were
'pooled' and thus much effort was used to ensure their uniqueness,
but even before the paradigm item change an item type could be
flagged as non-poolable. In that case, this already could fail
but with no too bad consequences (just one more copy of
an ScPatternAttr would stay).
So I fixed that mainly in adapting and optimizing
ScPatternAttr::operator==. The results are (same machine, same
compiler, dbg version, metioned test):
Version before item paradigm change:
user 0m50,778s
Version after item paradigm change:
user 20m13,944s
Version with memcmp:
user 0m48,845s
Version with hash:
user 0m48,710s
Since that hash does nothing else than to buffer the comparison of
those item pointers I just tried to use memcmp instead, as is already
used in other places (same file, ScPatternAttr::FastEqualPatternSets,
also SfxItemSet::operator==). As can be seen above it makes practically
no difference (memcomp even slightly faster).
Since that hash is only used in ScPatternAttr::operator== and is same
speed (memcomp linearly compares 56 SfxPoolItem ptrs) I decided to
remove it. It needs quite some spaces to be reset and re-calculated
which are not needed anymore. The calculation is based on dividing
the number of items by 4, so we are good with 56, but if someone has/
will adapt the items used by ScPatternAttr it is easy to forget to
adapt this, and not easy to change the alghorithm when it's not a
multiple of 4.
I also optimized/overhauled SfxItemSet::operator== (or better: the
SfxItemSet::Equals used by it). It is now better readable, too.
I also adapted ScAttrArray::AddCondFormat to not always incarnate/
delete ScPatternAttr instances, only when needed. This also helps
a bit and could be done in more places.
All in all it is really necessary to cleanup SC's usage of
ScPatternAttr - there are quite some possibilities to make that
cleaner and faster. In principle it's a huge 'compromize' to use
item functionailty to have a possibly 'cheap' maximum shared
SfxItemSet at a Cell.
Decided to make SfxItemSet::operator== even faster for the case
of unequal ranges by iterating over ranges of local SfxItemSet
and incremented offset. Still accesses to 2nd SfxItemSet will be
the expensive ones using the iterated WhichID.
Added two more things to SfxItemSet::operator==: We can return
early when both have no items set. For the unequal-ranges compare
I added an early-exit when Count() items were compared.
Looked at the errors that indeed do trigger the assert in
ScPatternAttr::operator== and hint to incarnations of ScPatternAttr
that do not use the needed range ATTR_PATTERN_START, ATTR_PATTERN_END.
Hunted down to come from ScViewFunc::ApplyAttributes and there from
some Dialogs, so seems some SC dialogs do not work with the correct
range schema for that item.
I tried code in ScViewFunc::ApplyAttributes to fix it, that works. I
also tried to hunt that down to the Dialogs that use the wrong schema
(TotalCount @SfxItemSet is 61 BTW). While it would be possible to do
so, it's no guarentee to have this fixed.
Thus I looked at ScPatternAttr::ScPatternAttr and added correciton
code when one with the wrong range schema gets created, this is
luckily not often needed and transfers the existing items with low
costs.
Maybe we should add a warning there if used, so at least new
implementations of stuff or old ones (the Dialogs) can be corrected?
Change-Id: I31da73ae30786bd6c5a08a5e3b7df8fe279af261
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159592
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
* Update helpcontent2 from branch 'master'
to 579bf8dd91ebc66108f8710452ea2280c81c1223
- use "export" instead of "print" at PDF export options page
Change-Id: I1c1bfcfab57b74129c5bb60fad89376c88e64dfd
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/159638
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
so the forked processes don't need to
Change-Id: Id37688ac88c14679e216cca744563ee75c7c4736
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159561
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
At least some old versions of systemd-run apparently have occasional issues when
sequential invocations reuse the same --unit value, as
<https://ci.libreoffice.org/job/lo_ubsan/2982/> now (i.e., after the machine was
updated to auto-detect --with-coredumpctl) failed with
> [build CUT] basctl_dialogs_test
> LO_TEST_LOCALE=de
> Running scope as unit: -home-tdf-lode-jenkins-workspace-lo_ubsan-workdir-CppunitTest-basctl_dialogs_test.test:20231117013657:704127.scope
[...]
> LO_TEST_LOCALE=en-US
> Running scope as unit: -home-tdf-lode-jenkins-workspace-lo_ubsan-workdir-CppunitTest-basctl_dialogs_test.test:20231117013657:704127.scope
[...]
> LO_TEST_LOCALE=fi
> Failed to start transient scope unit: Unit -home-tdf-lode-jenkins-workspace-lo_ubsan-workdir-CppunitTest-basctl_dialogs_test.test:20231117013657:704127.scope already exists.
Change-Id: If009e26231228bec739637e4140be90c0b86d6b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159569
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Just as
commit 2105f638fa
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Nov 17 09:11:42 2023 +0100
android: Update app icon to new startcenter icon
updated the main icon for the Android app, also update the
MIME type icons that are shown in the "Recent files" section
in LibreOfficeUIActivity to the new ones meant to be used
for Calc/Draw/Impress/Writer since 7.5.
Change-Id: I1d969a290caa3c23589e78151cd5bf70144c3099
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159568
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
it in several places. Currently these places get a Sequence<sal_Int8>
by call of StaticTokenMap().getUtf8TokenName() and immediately after
that generate an OUString from it using reinterpret_cast<const char*>
and the OUString ctor with 8-Bit character buffer array. The patch
moves this conversion to StaticTokenMap.
Change-Id: Ia2af110e2a0f1708e0685115d325c1c12cab3857
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159514
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Added the SID_ATTR_PARA_SNAPTOGRID to the alignment ranges in order to
reset the snap to grid option to the corresponding parent setting.
Without this parameter, the main dialog does not have any knowledge
about this option.
Change-Id: Ib090fae0919be54dd41674d129f5355c3566a90c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159565
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Update the icon used for LibreOffice Viewer
with the new icon used since LibreOffice 7.5 [1].
Use the startcenter icon from `sysui/desktop/icons/hicolor/`
and export for the required resolutions where it doesn't exist
yet.
[1] https://wiki.documentfoundation.org/ReleaseNotes/7.5#Design
Change-Id: Ie9f59d42bbc9375e7ca433c6452223b7ba3033a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159554
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of duplicating the icon as drawable,
just use the one from the mipmap folder that's
used for the app launcher.
Change-Id: Idd6691c4639fb570357280cec63636d07fe06b20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159553
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Word has an easy UI to turn floating tables into inline ones. Writer had
a similar button, but that had a few shortcomings:
1) It was only visible if a non-split frame was too large to fit the
page.
2) It was a separate VCL widget, so invisible to LOK clients.
3) It only worked for frames which had a single table in them.
Researching the problem, it's interesting how deleting a frame always
deletes its content as well, but e.g. deleting a section just removes
the container but leaves the content in the body text.
Fix the problem by adding a new menu item in the context menu that
always allows converting the frame to inline content at the anchor
point. This can share a bit of code with the old unfloat button.
The undo/redo still needs fixing, in a follow-up change.
Change-Id: I8ce05c9f958b08cb599fd5d2a27e770182f28cc7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159550
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
