When there are multiple competing configuration settings for the same
configuration layer (e.g., in xcu files of two different extensions from the
same extension layer), then the setting that is read last always won, even if
any of the settings read earlier is marked as finalized. (The reason for
originally doing it that way was that it kept the code logic somewhat simple.)
However, esp. for a scenario of multiple extensions in one extension layer
(bundled, shared, or user), it can be unexpected by a user that a non-finalized
setting (that comes from the extension that happens to be read last) can win
over a finalized one.
Therefore, change the logic accordingly. Now, if any of the competing settings
are finalized, the first finalized one that is read wins.
Change-Id: I22aeade543a5b26d95d49cfcb561f974cd7a5081
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177737
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...new with GCC 15 trunk -std=c++26 since
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=cc67d95dc100706ea665e8cce581d59466aba62e>
"c++: Implement C++26 P3176R1 - The Oxford variadic comma",
> In file included from workdir/UnpackedTarball/boost/boost/rational.hpp:82,
> from source/external/boost/include/boost/rational.hpp:30,
> from source/tools/source/generic/fract.cxx:32:
> workdir/UnpackedTarball/boost/boost/integer/common_factor_rt.hpp:66:56: error: omission of ‘,’ before varargs ‘...’ is deprecated in C++26 [-Werror=deprecated-variadic-comma-omission]
> 66 | inline constexpr void constexpr_swap(T&a, U& b...) BOOST_GCD_NOEXCEPT(T)
> | ^~~
> | ,
and
> In file included from workdir/UnpackedTarball/boost/boost/move/unique_ptr.hpp:24,
> from workdir/UnpackedTarball/boost/boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp:18,
> from workdir/UnpackedTarball/boost/boost/spirit/home/classic/core/non_terminal/grammar.hpp:21,
> from workdir/UnpackedTarball/boost/boost/spirit/home/classic/core.hpp:42,
> from workdir/UnpackedTarball/boost/boost/spirit/home/classic.hpp:24,
> from workdir/UnpackedTarball/boost/boost/spirit/include/classic.hpp:11,
> from source/external/boost/include/boost/spirit/include/classic.hpp:30,
> from sdext/source/pdfimport/pdfparse/pdfparse.cxx:23:
> workdir/UnpackedTarball/boost/boost/move/detail/unique_ptr_meta_utils.hpp:500:39: error: omission of ‘,’ before varargs ‘...’ is deprecated in C++26 [-Werror=deprecated-variadic-comma-omission]
> 500 | struct is_unary_function_impl<R (*)(T0...)>
> | ^~~
> | ,
Change-Id: I56856e274a7c577c53d96343992bb79d4c3d602e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177730
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
* Update translations from branch 'master'
to 93f61b8759efdb510d3e24eac33e10c8231aedf8
- Updated Slovenian translation
Change-Id: I0f24e5a42d5d8650fec3dc21d199882691bbdbba
This is needed for online, so the sidebar fills all the available
transitions.
Change-Id: Id3af1ed0272305fe7f1ab2d5dddd967276bbbb3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177727
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
We need to check rather the update button is visible instead of the
expanders.
Regression from commit: 13ac356a32
(tdf#164048 sw a11y: improve error/warning levels with...)
Change-Id: I63fb5906ad2f7bb13bc5822c284861a419897c4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177723
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Shows an icon in the statusbar if autocalc is off;
clicking the icon toggles autocalc on
Change-Id: I7fb3296281647583f6f761427d35dcd79282f06c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177418
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Version number was accidentally downgrade after re-saving with glade.
Change-Id: I266280884739dba65e97804d542f358a20e575f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177717
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
For some unkown reason (maybe due to the macOS two-level namespace?)
including the $(ICU_LIBS) link flags causes a crash on startup in
the macOS dynamic library loader on some versions of macOS running
on Intel machines. LibreOffice 24.8.3 and earlier did not have this
bug since libraptor2-lo was not linked against libicuuc. So, revert
back to the LibreOffice 24.8.3 macOS build behavior.
On macOS, libraptor2-lo still links successfully even without
libicuuc and the bundled JavaScript HelloWorld macro still runs. So
it appears that libraptor2-lo does not need any symbols in libicuuc
or, if it does, libicuuc has already been loaded by the time
libraptor2-lo is loaded.
Change-Id: I2e09ce57b5f7aea631a522f5d33f3a4b1ebfd419
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177594
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
windows build doesn't make use of system libraries, so we only need to
make autoconf/configure happy (allow it to use PKG_CHECK_MODULES macro)
but for that adding the m4/mac path is enough (there's nothing mac
specific, just the pkg-config macros have been added for mac initially)
Change-Id: Ia5db12833c26d89b7e0dbd7009562836885d8055
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177562
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
i.e. strawberry-perl-portable for the installsets and openssl
The only module that needs to be installed (and only when building
installation sets) is Font::TTF::Font - but only on the windows side,
not in the wsl-container.
in the wsl-as-helper case there are three different versions of perl
involved:
* one inside wsl, since autogen.sh is a perl script
* one provided by git-bash - used for the majority of the build
whenever a recipe uses perl
* and strawberry-perl-portable for building openssl (since that is
picky and needs one that handles the windows-paths a certain way)
and for building the installation sets (because of similar
assumptions in path mangling)
Change-Id: I8374749f21c7862f2e9e77d760077e836a6e9166
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177560
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Similarly to Filters, Column Fields, Row Fields, Data Fields boxes
the Available Fields box should be enabled to expand horizontally.
Change-Id: I36a6322ef528a18e2c37eb8f3397cf1aeeedc759
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177680
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Regression from commit 14c6cde779:
"tdf#49885 Updated CJK BreakIterator to use ICU"
Previously, languages requiring dictionary-based break iterators were
handled by instantiating a stock ICU break iterator as a special case.
tdf#49885 upgraded our custom rules to support passthrough for
dictionary-based breaking, so this special case is no longer necessary.
Change-Id: Iebb06de82eb511946e5b220e5dc414440838b03c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177713
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
This change fixes an infinite recursion crash while updating kashida
insertion positions. This crash could occur if a word is too long to fit
on a page and is broken onto another line, with the best-fit valid
kashida insertion position on the previous line, and the following line
also containing valid kashida insertion positions.
Change-Id: Ifc3320765f35ccdc49bbf179446bc03654e2596d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177709
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
MenuBar::GetWindow() and MenuBar::getMenuBarWindow
return a pointer to the same object, so there's no
need to use + check both for null.
Change-Id: I1b7065e4cd04a24e6215118a8dc71f147ed75132
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177699
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
pMenuBarWindow is non-null and was already dereferenced earlier
anyway.
Change-Id: Ieaeda4129d5c819fefa37dd3a186f76e035961b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177698
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This avoids the need to do a dynamic_cast and makes
clear that this method always gets called with either
a window of a proper type or nullptr.
Change-Id: I8ca4020476c806ad423379c7c7ee6fdc6ceccd3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177697
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use `pWindow` only to assign initial value to
`pMenuBarWindow`, then consistently use only the latter
instead of keeping both in sync and using interchangeably.
This also prepares for changing the `pWindow` param
from `vcl::Window*` to `MenuBarWindow*` in an upcoming
commit without upsetting clang plugins.
Change-Id: I07482e23c365ce39c4aa581fb42bf97ad03f6e1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177696
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Merge PopupMenu::PrepareRun into its only caller
which makes it a little easier to follow the logic
and track what's assigned to what local variable than
when using many out params.
Change-Id: Id967040a579e3f6532afa523215049bdb68f1cd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177694
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Application doesn't need access to any private members.
Change-Id: Ia69b64ecf8e380b0b8da7477e3a3c7d312629965
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177693
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
MenuFloatingWindow is the window used of PopupMenu,
while the window for MenuBar is MenuBarWindow.
MenuFloatingWindow only needs access to the menu
bar's MenuBarWindow, so make MenuBar::getMenuBarWindow
public and no longer let MenuFloatingWindow be a
friend of MenuBar, to make a little clearer who
is able to access whose private members,...
Change-Id: I7ee492e36d6e94884d1dba652d11f26cb8543a52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177692
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
... and reset the view options that are toggled in
testHiddenParagraphFollowFrame and testHiddenParagraphFlys.
Backporting these tests to the libreoffice-24-8 branch broke 2 unrelated
tests because of the changed view settings:
Test name: (anonymous namespace)::testHiddenSectionPageDescs::TestBody
equality assertion failed
- Expected: 532
- Actual : 798
- In <>, attribute 'height' of '/root/page[2]/body/section[1]/infos/bounds' incorrect value.
xmltesttools.cxx:203:Assertion
Test name: (anonymous namespace)::testTable0HeightRows::TestBody
equality assertion failed
- Expected: 28
- Actual : 22
- In <>, XPath '/root/page[1]/body/tab/row' number of nodes is incorrect
Change-Id: Ie58242348fecabe163e54048f3896c6d427d2608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177691
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Pane shells (BottomImpressPane, LeftImpressPane etc.) do not implement any slot
handling, so make sure they are not activated on the top of the shellstack.
Another solution for this could have been getting ChildWindowPanes properly
dispose instead of Hide() at BasicPaneFactory::releaseResource, and adapting the
rest of the code which assumes these Panes are recycled.
This is since ConfigurationUpdater::UpdateCore attempts at releasing via
ConfigurationUpdater::CheckPureAnchors and
ConfigurationControllerResourceManager::DeactivateResources calls.
But in the end the ChildWindowPane is hidden on the DeactivateResource call
instead of being diposed, so the "PureAnchor"'s Shell stays at the shellstack.
Change-Id: I52788d350b66ae22875683f57d87326f4a9a77de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177686
Reviewed-by: Sarper Akdemir <sarper.akdemir@allotropia.de>
Tested-by: Jenkins
field text ended in \ so next } was escaped
Change-Id: I2129f410a1d1c3d507a223c3576f02b78f7aac63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177681
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
... instead of manually casting the `m_pWindow`
member in another place.
While at it, also just call GetWindow()
in PopupMenu::ImplGetFloatingWindow, not explicitly
the base class Menu::ImplGetFloatingWindow. Both
are the same, as this is a non-virtual method
only implemented in the base class.
Change-Id: I12debc7c5bad8b21722fabb093cbc4a7a669dff1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177672
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
MenuFloatingWindow::pMenu is always a PopupMenu,
so use a VclPtr<PopupMenu> for it, instead of
a VclPtr<Menu> and casting in multiple places.
Change-Id: I004fc57063fc1cd50e5f14463367af3063a247b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177671
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Have a default SalMenu::GetSystemMenuData implementation
that does nothing instead of being purely virtual
and all subclasses except WinSalMenu::GetSystemMenuData
having to override it to do nothing.
Change-Id: Ia47af286f0fd3c1e3c6a00fff4512c9334fd6e9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177660
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
