Age | Commit message (Collapse) | Author |
|
...to reflect whether or not the corresponding item can be modified. Which
matches what the READONLY flag is actually used for today. (And the original,
somewhat arbitrary semantics had been assigned without much thought, IIRC, and
it should be OK to change them.)
Change-Id: I8185e47519a5cb4aff6e8f260326845276b0c092
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160957
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I8c617c20f725f4277a0c4d637be336c6624c3238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160513
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: Ib8bbb7fc9e8014a9367278f3fa640f53af46dd2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159986
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
(Localized)PropertyType::getStaticType already provides the relevant information
Change-Id: I5aceb596ac4a2d111ebcb5ddef7ef74c80762047
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159969
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...it only pertains to property nodes
Change-Id: I706e14118e3f8c33190821f9bcce81bd60d665e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159953
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
ever since
commit a91892ec4942fc875820ea02dfbe74e986548142
Author: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Date: Thu Nov 16 13:56:06 2023 +0100
Use existing types, instead of strings
Change-Id: Ifb7af17d21a32fdf411854b6820b32d1767660e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159779
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
as suggested in https://gerrit.libreoffice.org/c/core/+/158028/comments/b7a803f4_7e5899ca
Change-Id: I7d4c46b24307922b51e463bacdfacfca85956b80
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159524
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Change-Id: If9cc1f0c18a5fa344a433b338f81d191340e70f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159722
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
In preparation for proper editing support for the different types.
Change-Id: I7044ff100c9bfcca5fa8894ff4525a1aac692796
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158028
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Change-Id: I7d0257c2e06ed384f90ca3b51a6d2549044f2cf3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157148
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
we can return by const& from getNode
Change-Id: If93c43fd2e910e2fb69d9bd0a9e3dc587133dfa8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158729
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
no need to construct a vector when iterating over children
Change-Id: I717e92be3c576a6e5d877f4333264a5bed9daadf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158728
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id95245a309b3baa80d7cca63d980aa0657fb9eb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158148
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
reduce log noise
Change-Id: I95393f18fe8cc019c89ad4779d5b10f64993bd51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156340
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The problem appeared when in a configuration listener's changesOccurred,
a configuration value was read using officecfg machinery, which could
return the old value of the configuration, or an updated one, at random.
This was caused by use of a cached value in
comphelper::detail::ConfigurationWrapper::getPropertyValue, which is
cleaned in ConfigurationChangesListener::changesOccurred; but the order
in which the listeners' changesOccurred methods were called depended on
the implementation detail of configmgr::Components::roots_, which was
previously a std::set of pointers, and now is a sorted vector. This
made the pointers sorted in order of the pointers' addresses (basically
random), and when a broadcaster's common list of change listeners was
prepared in Components::initGlobalBroadcaster, ConfigurationWrapper's
listener could arrive last. This meant, that the cache could be cleaned
too late, after its obsolete content was already used in a previous
listener.
The problem could be partially mitigated by clearing the cache in the
comphelper::detail::ConfigurationWrapper::setPropertyValue, but that
would only handle cases of config modifications using comphelper.
Instead, take into account that ConfigurationWrapper listens on the
root of configuration tree; and introduce a separate container in
configmgr::Broadcaster for root listeners. They would be triggered
first, before all other listeners.
Still, this would not guarantee the proper order, if another listener
is registered on root. To handle all cases, a special listener category
could be used, which could be filled using a dedicated internal API, so
comphelper could use it to register its privileged listener close to
the heart of the broadcaster :) This might be implemented later.
Change-Id: I956b7989b3927dca2683f63cf92b0dda04db9bdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154561
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ia7d9475cecd2208ccf672f2b35c0c841fed7f4dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150840
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
found with a lightly tweaked version of the loplugin:stringadd
and some hand-holding.
Change-Id: I146aadcaf665e98fea89a9cad2df4dc3935622f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152275
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...after abd630e81bc150d05e4129cc22752ecf461777c7 "Allow all hierarchical path
segments to be ['...'] quoted", which failed as the checked
MimeTypeClassIDRelations group is conditional on install:module="reportbuilder".
(See the comments at
<https://gerrit.libreoffice.org/c/core/+/151673/2#message-f029dd1877f8a946647456ed73a7b60f6dfc0e8f>
"Allow all hierarchical path segments to be ['...'] quoted".)
It looks like there is no other, non-conditional property with a slash in its
name, so the test now just tests the ['...'] syntax on an otherwise
unproblematic property name. (Alternatively, we could have extended the
configuration data used by unit tests with such a problematicaly named
property.)
Change-Id: I820004a5b824326d86e67c158994f13e71ba135e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152184
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...and not just set elements. <https://gerrit.libreoffice.org/c/core/+/151660>
"tdf#104005 Don't allow changing finalized properties" found that some existing
property names include "/", which makes them unusable with e.g.
getPropertyByHierarchicalName.
The most obvious solution is to allow ['...'] quoting (without a leading
template name, though) for all kinds of hierarchical path segments. (In theory,
that would cause backwards incompatibility, as e.g. a property named ['foo']
could no longer be referenced by a ['foo'] path segment (it would need to be
referenced by a ['['foo']'] path segment instead). But in practice,
that path segment ['foo'] would have been rejected in the past anyway, as it did
not reference a set element.)
To make this work, the meaning of the setElement out-parameter of
configmgr::Data::parseSegment is changed to only be true if the segment uses
['...'] notation including a leading (non-empty) template name.
What this change does not (yet) address is writing out such quoted (group or
set) names in the hierarchical paths written out in configmgr::writeModFile,
where necessary. (It never writes out names of properties as parts of
hierarchical names, so this wouldn't be an issue for the existing problematic
properties containing "/" in their names, anyway.)
Change-Id: I635d823c7bbb6b8ac5869c7e0130ba8cfd329599
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151673
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Instead of doing two lookups, we can just call insert and
then update the mapped-to value if the insert actually succeeded.
Change-Id: I3df3b98f0debe6bf74c739dd5850e7714d9c2789
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151030
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1cf871b40f9f4020147dac0456ebeed3de0438e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150533
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
after my patch to merge the bufferadd loplugin into stringadd
Change-Id: I66f4ce2fd87c1e12eefb14406e0e17212f68ceff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149497
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6898acbf7c6c9de45bbfa6a32202acf302f92caa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146822
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
At least building on Fedora 37 with dconf-devel-0.40.0-7.fc37.x86_64 against
recent LLVM 17 trunk libc++ started to fail now with
> In file included from configmgr/source/dconf.cxx:25:
> In file included from /usr/include/dconf/dconf.h:23:
> In file included from /usr/include/dconf/common/dconf-enums.h:23:
> In file included from /usr/include/glib-2.0/glib.h:34:
> In file included from /usr/include/glib-2.0/glib/gasyncqueue.h:34:
> In file included from /usr/include/glib-2.0/glib/gthread.h:34:
> In file included from /usr/include/glib-2.0/glib/gatomic.h:30:
> In file included from /usr/include/glib-2.0/glib/glib-typeof.h:44:
> In file included from ~/llvm/inst/bin/../include/c++/v1/type_traits:430:
> ~/llvm/inst/bin/../include/c++/v1/__type_traits/aligned_union.h:23:1: error: templates must have C++ linkage
> template <size_t _I0, size_t ..._In>
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> configmgr/source/dconf.cxx:19:1: note: extern "C" language linkage specification begins here
> extern "C" {
> ^
because the missing extern "C" has meanwhile been added to upstream dconf with
<https://gitlab.gnome.org/GNOME/dconf/-/commit/f860ddcc6a501b982d82c5630c73936bd611ad8a>
"common: Add missing G_BEGIN/END_DECLS" towards tag 0.40.0.
So the easiest fix here appears to be to bump our requirements to that dconf
version 0.40.0: The one case I'm aware of that explicitly wants dconf support
is downstream Fedora and RHEL builds, which already have dconf 0.40.0
(cf. most recent
<https://src.fedoraproject.org/rpms/dconf/blob/a9987b0abe15133d091bcd390fd33077881567ae/f/dconf.spec#_4>
for f37 and most recent
<https://gitlab.com/redhat/centos-stream/rpms/dconf/-/blob/1bb6b46da242b75e5e1864f5c97ab6e592ca60ba/dconf.spec#L4>
for e9s). On the other hand, the TDF Linux release builds are done with an
explicit --disable-dconf in distro-configs/LibreOfficeLinux.conf (since
ecc617e797aa5ed329668114e54ec7ffa5c0e87b "configmgr: support reading from a
dconf layer (WIP)") and the Flatpak builds on Flathub are done against an
org.freedesktop.Sdk//22.08 where no dconf support is detected at all (for the
most recent LO 7.5.1 build on Flathub see
> checking for DCONF... no
> checking whether to enable dconf... no
at <https://buildbot.flathub.org/#/builders/5/builds/3184/steps/8/logs/stdio>
for aarch64 and at
<https://buildbot.flathub.org/#/builders/5/builds/3184/steps/8/logs/stdio> for
x86_64).
Change-Id: I559d2ac8712dbe2b40c9b881314b88d1cc8eaf43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148887
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Since the code that can run during flushModifications might manage to
call back into Service..
regression from
commit a61951a3a21c6457334f78f657806c1167dbf339
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Feb 20 20:08:30 2023 +0200
BaseMutex->std::mutex in configmgr::configuration_provider::Service
Change-Id: I0070e7589cdea38905de6c68adefd8081b122152
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147500
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
a mistake from
commit a61951a3a21c6457334f78f657806c1167dbf339
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Feb 20 20:08:30 2023 +0200
BaseMutex->std::mutex in configmgr::configuration_provider::Service
Change-Id: I59c670ea7bffacb9dcd1f073b5da2439c2102a45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147392
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie8f7cb4cd91ac0089365a691f07962a26d51a72a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147377
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...after b52117c0be97c45824d2897657084f8ac7e9bf42 "Try an override locale as
first fallback"
Change-Id: I23d8459fff4d76fd9d542d098953bf97cf5397a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147219
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after a9b97301ba75a74e6671a6b9829f7044e85db6af "Do not add empty language tag
to fallback strings"
Change-Id: Ie42929c2ce6331012358f72026ae774b9dd0e369
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147207
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I4ca6db43fef2706c4c1bab020e2170f6cf45a441
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147184
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
This happened for known tags like es-419 but unhandled in
simpleExtract(), which actually should be implemented as now a few
are mapped as known tags. Prevent adding such empty string.
For that, adjust configmgr/qa/unit/test.cxx to test for the
expected "en-US" instead of "default".
Change-Id: I05f8e35a9d88b42d45e1f2a90aecec5f4470cc79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147135
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
c3bd52f81bf733a0b9b0560794a54b2ac1e0f444 "Use the (first segment of the)
original locale value for the workaround again" had stated: "The added test
code unfortunately doesn't actually test this piece of code, and somewhat
unexpectedly receives the "default" value from the empty string locale default,
rather than the "en-US" value from the higher precedence "en-US" locale default,
because `aFallbacks` happens to contain an empty string, so we already leave
Access::getChild early in the 'Find the best match using the LanguageTag
fallback mechanism, excluding the original tag' block." But, of course, the
relevant code can well be tested after all, using a localized property that
does not have a default no-xml:lang value.
(And add a TODO comment about the unexpected "default" vs. "en-US" in the
original test code, in case the LanguageTag::getFallbackStrings behavior ever
changes and the test starts to fail.)
Change-Id: I526a830a5929b6b5ad17ba57af5943954b07b86a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147137
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
cf7c9599e776eba8e14614cecb528d3da5778190 "Make comphelper/configuration.hxx work
for localized properties", which had originally introduced this code, had been
careful to ensure that the
> assert(
> !locale.isEmpty() && locale.indexOf('-') == -1 &&
> locale.indexOf('_') == -1);
would always hold here (it had already removed all trailing "-..." and "_..."
segments, but had made sure to stop before `locale`, which is known to initially
be no non-empty, would have become empty, by treating a leading "-" or "_" not
as a segment delimiter, but rather as a first segment).
dfc28be2487c13be36a90efd778b8d8f179c589d "configmgr: Use a proper
LanguageTag-based locale fallback mechanism" had changed that, instead setting
`locale` to some value obtained from `LanguageTag::getFallbackStrings`, which
might or might not satisfy the assert.
But there was no good reason for that part of
dfc28be2487c13be36a90efd778b8d8f179c589d in the first place: The workaround (as
explained in the leading code comment) was meant to be carried out with the
first segment of the original `locale` value, not with some fallback value. So
put back here the computation of that first segment of the original `locale`
value. (And drop the misleading empty line that
dfc28be2487c13be36a90efd778b8d8f179c589d had, for no good reason, introduced
between the workaround's leading code comment and its actual code.)
However, it turns out that there was one flaw in
cf7c9599e776eba8e14614cecb528d3da5778190: When the original `locale` starts
with "-" or "_", the resulting `locale` representing the first segment will be
"-" or "_", so the `locale.indexOf('-') == -1 && locale.indexOf('_') == -1` part
of the assert would be false. But that wouldn't be an issue for the following
code (the only issue would be if `locale` had become empty, in which case the
`name2.startsWiht(locale)` check would trivially become true, and that for loop
would erroneously pick the child with the empty `name2`), and that part of the
assert had merely been there to reinforce that `locale` had indeed been stripped
down to the first segment. A correct version of the assert would have used
`locale.indexOf('-', 1) == -1 && locale.indexOf('_', 1) == -1` instead, but as
the code now makes it obvious anyway that `locale` has been cut down here to the
first segment, we can just as well simplify the assert to just the
`!locale.isEmpty()` part.
(The added test code unfortunately doesn't actually test this piece of code, and
somewhat unexpectedly receives the "default" value from the empty string locale
default, rather than the "en-US" value from the higher precedence "en-US" locale
default, because `aFallbacks` happens to contain an empty string, so we already
leave Access::getChild early in the "Find the best match using the LanguageTag
fallback mechanism, excluding the original tag" block.)
Change-Id: Ib92e714c9db4879be058529ec905e631df975424
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147113
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I9abe06e6f1f2b6b39cbbf07043dd9c5062ff0460
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147108
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...left behind by 6a370f580aaf060004536dfc8ca877c9a2114c66 "configmgr: remove
unused old dmake file"
Change-Id: I9209b672f0b3242f6801935722b3108ef692787a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147096
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic8f688d3ad66c1be33a147e05b0e9145593214f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146471
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia92bb76cedb45d2c28482d34869e239cfdd32ebf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146470
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iadfdbb68ad7876801bf79352bdec26da7da63325
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145993
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This reverts the configmgr part of 0a7eac8576f313dcaf27ee45326d71fd6b5aea1e "use
more string_view in accessibility..configmgr": All calls to Data::parseSegment
(either directly, or indirectly either via Access::getSubChild or via
parseSegment in partial.cxx) pass in an OUString path, and in some cases (see
below)
> *name = path.substr(index, i - index);
in Data::parseSegment reconstructs an OUString from the full path (i.e.,
index == 0 and i == path.size()). And I see no code that actually benefited
from the switch to string_view.
One example call stack for such an expensive reconstruction of an OUString from
full path is
> #0 in configmgr::Data::parseSegment(path=u"ooSetupSystemLocale", index=0, name=0x7ffff5299280, setElement=0x7ffff52992a0, templateName=0x7ffff52992b0) in core/configmgr/source/data.cxx
> #1 in configmgr::Access::getSubChild(this=0x619000028f80, path=u"ooSetupSystemLocale") in core/configmgr/source/access.cxx
> #2 in configmgr::Access::getByHierarchicalName(this=0x619000028f80, aName="ooSetupSystemLocale") in core/configmgr/source/access.cxx
> #3 in utl::ConfigItem::GetProperties(xHierarchyAccess=uno::Reference to (configmgr::RootAccess *) 0x619000028fb8, rNames=uno::Sequence of length 6 = {...}, bAllLocales=false) in core/unotools/source/config/configitem.cxx
> #4 in utl::ConfigItem::GetProperties(this=0x61100000cad0, rNames=uno::Sequence of length 6 = {...}) in core/unotools/source/config/configitem.cxx
> #5 in SvtSysLocaleOptions_Impl::SvtSysLocaleOptions_Impl(this=0x61100000cad0) in core/unotools/source/config/syslocaleoptions.cxx
[...]
Change-Id: I51127d82aea927dd9aaf374880c406dbafaddcde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140658
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie16d36faac7d06e275348ed68e6c6b2518534fd6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140636
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...avoiding to have code in configmgr that knows about the details of the data
stored in the configuration. (See the comments starting at
<https://gerrit.libreoffice.org/c/core/+/139690/9#message-44703a2529c07bf1b0202ed3a232aa661784b159>
"Migrating product name related color schemes between different versions" for
details.)
This reverts the dubious changes of 583ea856f2aa227bb04581c5bcdc3a402f5a184f
"Migrating product name related color schemes between different versions" in
configmgr and offapi. (Also, this moves the computation of sMigratedProductName
in MigrationImpl::copyConfig, desktop/source/migration/migration.cxx, to a saner
location than in the middle of the "check if the shared
registrymodifications.xcu file exists" block where that
583ea856f2aa227bb04581c5bcdc3a402f5a184f had placed it.)
Change-Id: I7ab3d57db19065c7c818e697300a2abd9e7f72bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139963
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Making work to migrate product name related color schemes
with different kind of product names. For example from a product
named by LibreOffice to a product named by LibreOfficeDev.
Change-Id: Iabef982216f126b781df122ed258816af2ae337c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139690
Tested-by: Jenkins
Tested-by: Gabor Kelemen <kelemeng@ubuntu.com>
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Id81a0c0046d0d84e6c327eef4447b21fecae6ddc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137283
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If2e69c04e4d72ec6911fb435092275dbfffbf991
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134752
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Fixes build breakage on macOS at least. Noel said it was OK to revert.
This reverts commit cc4325f84a0ba35d8bbb564512bce0c6b8aab408.
Change-Id: Ib78d29fc21d4d030b4032955b18271de1761f396
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134458
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
reduces time spent allocating
Change-Id: Idd571db62d28be7e48672f76d741174a7ab40959
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134346
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9a875d5615930700e20f67c40b4b7a24458fd447
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134198
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3062855ab8f9ec9f1e7cdffe163f1c78865d5b9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134154
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|