this was skipped in previous runs, since it contains some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
Change-Id: If1e3e3c7c0fc14ed6e8b51174a0e7f1220fdbc8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197496
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Replace by operator[], begin() and end(), which don't have overhead
since commit 2484de6728 (Remove non-
const Sequence::begin()/end() in internal code, 2021-10-15)
and commit fb3c04bd19 (Drop non-const
Sequence::operator[] in internal code, 2021-11-05).
Change-Id: I221470b3439bb0dc6e7705b0d99deb3cd2063484
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195176
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The XCUBasedAcceleratorConfiguraton reloads the configuration for a key
when a change notification on that key is received. However if the
change event was triggered by deleting a key then the change path
doesn’t contain a command and the code was ignoring it. The
reloadChanged function seems to already almost be designed to handle the
case when there is no command in the configuration. In that case it
deletes the key which seems like the right thing to do. However, when a
new key is assigned an event first gets fired for the key with no
locale, so the code needs to additionally handle that case now.
I don’t think this has any practical implications unless it’s possible
to have two instances of an XCUBasedAcceleratorConfiguration for the
same module open at the same time. However, this patch alone can work as
an alternative way to fix the problem described in
96491f3f84 because it would cause the
deleted key from the module config to also be deleted in the global
config.
It looks like the check for sPath was added in
7492878a15.
Change-Id: Ia90a1932e3169ca28157482c3035aba7efae012a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190972
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The XCUBasedAcceleratorConfiguration-s get registered as config change
listeners in ModuleAcceleratorConfiguration::fillCache and
GlobalAcceleratorConfiguration::fillCache. The reloadChanged method then
finds the appropriate config based on the path of the change event.
However, the code didn’t do anything to check whether the config is
actually the one being managed by this accelerator configuration. That
meant for example that if a key was changed in the module configuration
then the global configuration would get notified and it would end up
replacing its configuration for that key with the module one. It would
also end up in the accelerator configuration for modules for any other
documents that happen to be open.
One way to manifest this bug is as follows:
• Create a new text document
• Tools → Customize
• Select the keyboard tab
• Select F7 in the list of keys
• Type “word count” in the search box
• Press “assign”
• Press OK
• Tools → Customize again
• Select F7 in the list of keys
• Press “delete”
• Press OK
Now look at the tools menu. Notice that F7 is still assigned to the word
count option. This is because the key has been copied into the global
configuration. The delete only deleted it from the module configuration.
Note that the messed up configuration is only stored in the read cache
so it doesn’t end up getting saved. If you restart LibreOffice then the
expected behaviour is restored.
This problem might have been added in e9e75d722d. It looks like before
that it might have been adding separate listeners for global and module
configs. Ie, connectToResourse has either PresetHandler::E_MODULES or
PresetHandle::E_GLOBAL.
Change-Id: Iac8f50f3668eaadc9a62f562d5923b93cc3d0721
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190971
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
The accelerator cache maintains a 1:1 mapping for key→command and a
1:n mapping for command→keys. When a new command is set for a key it was
previously only updating the key→command map and then adding the key to
the command→keys map. It never removed the key from the command→keys map
for the old command. When the menus are eventually updated, it looks up
whether each item has a shortcut based on the item’s command. Because
the old command was never removed, this ended up making it display the
same key binding on multiple menu items.
Change-Id: I6d75834f4c49b1f5c105ec40cb27b8e73006152d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190928
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This change stops the creation of empty Configurations2/accelerator
dirs on new documents that do not have anything that needs to be stored
there. Previously, LibreOffice would always create this directory.
Whenever an XStorage is opened readwrite on a path, it will immediately
create that path. LibreOffice was opening all of these paths readwrite.
So, the solution is to always open these paths as readonly, and then
when we need to write data to them we close them and re-open them as
readwrite. If we never need to write data to a path, then it won't be
created.
This patch specifically stops the creation of subdirectories that were
being created by DocumentAcceleratorConfiguration.
Other patches in the relation chain handle paths created by
UIConfigurationManager and ImageManager.
Test coverage was added in b9054fed37
$ CPPUNIT_TEST_NAME="Test testTdf60700_accelerators" make CppunitTest_sw_odfexport
As far as I can tell, there is no way to actually attach custom
accelerators to a document at this time using the UI, so I did not do
any manual testing for this change.
(The closest thing to storing accelerators in the document is the work
from 65d2c9ca4d, but the macros don't
yet continue to work when you save the document in ODF)
With this change, a fresh document looks like this:
$ unzip -l Untitled\ 1.odt
Archive: Untitled 1.odt
Length Date Time Name
--------- ---------- ----- ----
39 2025-05-17 15:57 mimetype
0 2025-05-17 15:57 Configurations2/
12645 2025-05-17 15:57 styles.xml
899 2025-05-17 15:57 manifest.rdf
3563 2025-05-17 15:57 content.xml
866 2025-05-17 15:57 meta.xml
14745 2025-05-17 15:57 settings.xml
318 2025-05-17 15:57 Thumbnails/thumbnail.png
1061 2025-05-17 15:57 META-INF/manifest.xml
--------- -------
34136 9 files
Change-Id: I5e032d55e94114333ea7778afcc3df0fefe0a30f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185451
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Some of the exclusions were too aggressive. Restrict them to only the
important classes, which exposes some more places this plugin applies.
Change-Id: I1b2d1fb24391adc71ed0984f94168f61a149479f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165154
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
OUStringLiteral should be declared constexpr, to enforce
that it is initialised at compile-time and not runtime.
This seems to make a different at least on Visual Studio
Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
the next one is not displayed
This patch solve the part 2 of the bug, the problem was
that it did not take into account whether a command was assigned
multiple keys, it simply deleted the whole command
Change-Id: I4e09096d3bc112ed49a4210dd294d1acf7a48159
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147093
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
it is only used by the *AccelerationConfiguration classes, and they lock
the SolarMutex around all accesses to this data.
Change-Id: I07de415bae9e0aff679f693022b9181971f19bd2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146254
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
the = key is } on a french keyboard,
so remap the
ctrl-alt-=
shortcuts to
ctrl-alt-}
which means the user gets to keep pressing keys in roughly the same
physical location for this action, regardless of keyboard
Change-Id: I03e251dacc1c19e543182a44ae23fde2a57cfa45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139474
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which can use the more efficient *StringConcat
Also fix a crash in stringview plugin which
started happening while I working on this.
Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Gabor Kelemen