summaryrefslogtreecommitdiff
path: root/solenv
AgeCommit message (Collapse)Author
2023-03-17loplugin:rangedforcopy: Assume non-reference structured binding is intentionalStephan Bergmann
See pending <https://gerrit.libreoffice.org/c/core/+/149026> "tdf#148008: do not proceed after the marked range" for a use case. Change-Id: Ief7cbb215068b6f5428c16a72896ef5612204128 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149056 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-03-14Improve scripts that codesign and create a .dmg from a Universal bundlePatrick Luby
This change adds the following: - The solenv/bin/macosx-codesign-app-bundle script now uses "--timestamp" wherever "--options runtime" is used in order to pass Apple's notarization process. - A second, required argument has been added to the bin/create-dmg-from-merged-app-bundle script that specifies one of the following types: "release", "dev", or "collabora". Only the .DS_Store is different for each as no product set a volume icon currently. - Upon success, the bin/create-dmg-from-merged-app-bundle script will print a warning that the .dmg is not notarized as well as the commands to use to manually notarize the .dmg. Change-Id: I7c3f2d60dbb16b25bd6088b7e0af8c82284702d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148490 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Patrick Luby <plubius@neooffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit 86e612db56be2d1934275de021b3213875e9301d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148508 Tested-by: Jenkins
2023-03-08deduplicate MutexAndBroadcastHelperNoel Grandin
there are two very similar classes, standardise on the one in include/comphelper Change-Id: If85729dcea01e65a2d095bb211fe643c783ebf1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148442 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-03-01Re-enable Skia in Flatpak buildsStephan Bergmann
...as requested at <https://github.com/flathub/org.libreoffice.LibreOffice/issues/213> "Can Skia be reenabled in the Flatpak build?" and implemented on Flathub for now with <https://github.com/flathub/org.libreoffice.LibreOffice/commit/372d036e9113b6080780669ad44fc11a172356ed> "Re-enable Skia". (This partially reverts 9d88f11de57bcbeb29fa6f1299d5d0867c1a75a4 "Flatpak: Upgrade to 21.08 runtime, disable Skia".) Change-Id: I50039d431fd3e6ba4c0d859d71e42e744433806b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148054 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-28Remove compilerplugins/clang/test/cppunitassertequals.hxxStephan Bergmann
...which isn't needed anymore to suppress warnings from other plugins like loplugin:external ever since 45c06838e95c94445359536d84c6328fa8b17a66 "only unit-test one loplugin at a time". Also, the declaration of the function test in cppunitassertequals.hxx had already started to deviate from its definition in cppunitassertequals.cxx. Change-Id: I3fbc8a9a805bd5bc4d8afbf958edff04b89add3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148010 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-28Sync flatpak-manifest.in with FlathubStephan Bergmann
...including <https://github.com/flathub/org.libreoffice.LibreOffice/commit/0b06d2638bf0a1f1707229e7b15e73fbe4c96537> "Update gvfs to the current master" Change-Id: I23cbf8aec7771eda59f66733bcde6cdbed3d0ddd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147994 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-28tdf#148966: pptx: workaround for multiline fields followed by linebreaksSarper Akdemir
In Impress after fields that span multiple lines, a linebreak is already forced. (PowerPoint doesn't have such behaviour) Therefore if the imported pptx file has a line break after the multiline field - Impress ends up displaying an extra line break. This patch implements ignoring of a linebreak that follows after a multiline field during paint (when not in EditMode), using a compatibility flag. (IgnoreBreakAfterMultilineField) Change-Id: I1e6772424cc0eead06b53d104b06820038a81ea1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147408 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-02-24Fix build in a specific VS2022 environmentMike Kaganski
Building libraries in setup_native using VS2022 failed for me reproducibly for some time, with mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/reg_dlls.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_reg_dlls.mk:10: C:/lo/src/build/instdir/program/reg_dlls.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/reg4allmsdoc.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_reg4allmsdoc.mk:10: C:/lo/src/build/instdir/program/reg4allmsdoc.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/regactivex.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_regactivex.mk:10: C:/lo/src/build/instdir/program/regactivex.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/sdqsmsi.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_sdqsmsi.mk:10: C:/lo/src/build/instdir/program/sdqsmsi.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/sellangmsi.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_sellangmsi.mk:10: C:/lo/src/build/instdir/program/sellangmsi.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/shlxtmsi.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_shlxtmsi.mk:10: C:/lo/src/build/instdir/program/shlxtmsi.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/sn_tools.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_sn_tools.mk:10: C:/lo/src/build/instdir/program/sn_tools.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/odbcconfig.exe". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/dbaccess/Executable_odbcconfig.mk:10: C:/lo/src/build/instdir/program/odbcconfig.exe] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/instooofiltmsi.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_instooofiltmsi.mk:10: C:/lo/src/build/instdir/program/instooofiltmsi.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/qslnkmsi.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_qslnkmsi.mk:10: C:/lo/src/build/instdir/program/qslnkmsi.dll] Error 139 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/inst_msu_msi.dll". The file or directory is corrupted and unreadable. make[1]: *** [C:/lo/src/core/setup_native/Library_inst_msu_msi.mk:10: C:/lo/src/build/instdir/program/inst_msu_msi.dll] Error 139 It is caused by the -U_DLL and the first entries in gb_Library_use_system_win32_libs: libcmt, libcpmt, libucrt, libvcruntime. They are needed to make the denerated DLLs standalone, not dependent on presence of VCRT on the target system (they are called from installer, when VCRT may not yet be present). It seems to work OK for others, but somehow, this conflicts with the fastlink option on my system, so just avoid it selectively for these DLLs. Change-Id: I61f829682eb051944202bc7ef3578d6f43733030 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147628 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-02-16Use -O3 for Emscripten, seems to workTor Lillqvist
Change-Id: I7effd75355ff81e6d4f85b1c6047c7656bfbb915 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147006 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2023-02-16Add comment about using WASM exceptionsTor Lillqvist
Change-Id: I402bf56b89b3a18f854331915f827f7512fb05e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147152 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2023-02-12Avoid LOKClipboard harder on iOSTor Lillqvist
Change-Id: I2710a7537594c486878a68c630f762a24ac81c49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133017 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146739 (cherry picked from commit 069aae6be68d67b45222740de01467d11f15adfb) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146800 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2023-02-10Pass product name and not hardcoded "LibreOffice" to make_installer.pl -pTor Lillqvist
Change-Id: I9b2d84bcc18e21b325960f7057e259daa37234a5 Reviewed-on: https://gerrit.libreoffice.org/55640 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit 12d1b08aac8cc8c3176040efc7290377e380f0c4) Reviewed-on: https://gerrit.libreoffice.org/79128 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 0069417b55c99166aec5489ccef803eba25d2b4f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136842 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146741 Tested-by: Jenkins
2023-02-10Revert "check-last-commit: more detailed advice on using clang-format"Ilmari Lauhakangas
This reverts commit f59d449ecfc078765dfaa2e150a21a7e4b330932. Reason for revert: confusing Change-Id: If5924ff3952f344f7a418e80d4ceb774dea94430 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146707 Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2023-02-09check-last-commit: more detailed advice on using clang-formatIlmari Lauhakangas
Change-Id: I7e25acd02573c3e173eccefe9326dc42e2940f05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146688 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2023-02-06Make LOKClipboard available to other modulesSzymon Kłos
LOKClipboard has higher level dependencies (sfx2) so it cannot be moved to the vcl where SystemClibpoard instance is created. - introduce new interface LokClipboard to differentiate from SystemClipboard so we can have vcl's and lok's implementations at the same time - publish LOKClipboard using new interface for other modules by adding component file in desktop module Thanks to that when code calls GetClipboard and we cannot get clipboard assigned to the vcl::Window* (for welded widgets) in GetSystemClipboard correct instance is returned (shared clipboard for current view) so we can access content which was copied before. Previously always a new instance was created (with empty content). test ScTiledRenderingTest::testPasteIntoWrapTextCell was broken add some content to clipboard to simulate more real case and test the content copied Change-Id: I23c0298960a710c498646493f33122b908864cba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126310 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131644 Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Tested-by: Szymon Kłos <szymon.klos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135198 Tested-by: Jenkins
2023-02-02capture output of package command and add to log on errorChristian Lohmaier
creating packages failed here and the logs aren't all that helpful without the output of the command that failed. Reason it failed was that macOS thought that a volume with the same name was already mounted (but that didn't show up in Finder). With the output of the command easy to solve by just rebooting to fix that bogus state, but with only "command failed" you question what is different about that specific language, why would packaging that single language fail, … Change-Id: I1f46263f9ec9c9374da5afaa58f6c9939b6a1488 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145239 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2023-01-27Split long-running CppunitTest_sc_opencl_test in twoStephan Bergmann
At least the unrelated <https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/132372/> was killed after 20 minutes of no stdout/-err activity, with CppunitTest_sc_opencl_test still running. From its captured state, it looks like it was indeed still making progress rather than being stuck: During ScOpenCLTest::testLogicalFormulaXor, the main thread was waiting at ScFormulaCell::InterpretFormulaGroupThreading -> comphelper::ThreadPool::waitUntilDone, while four comphelper::ThreadPool::ThreadWorker threads were each at > #4 0x00007f70652f9234 in __gnu_debug::_Safe_iterator_base::_M_detach() () at /lib64/libstdc++.so.6 > #5 0x00007f7048d3e8e5 in __gnu_debug::_Safe_iterator_base::~_Safe_iterator_base() (this=0x7f703daa9f20) at /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/debug/safe_base.h:100 > #6 0x00007f7048d5d709 in __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<mdds::mtv::base_element_block* const*, std::__cxx1998::vector<mdds::mtv::base_element_block*, std::allocator<mdds::mtv::base_element_block*> > >, std::__debug::vector<mdds::mtv::base_element_block*, std::allocator<mdds::mtv::base_element_block*> > >::~_Safe_iterator() (this=0x7f703daa9f18) at /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/debug/safe_iterator.h:86 > #7 0x00007f7048d5d6cd in mdds::mtv::soa::detail::iterator_updater<mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>::const_iterator_trait>::grouped_iterator_type::~grouped_iterator_type() (this=0x7f703daa9ec8) at workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector/soa/./iterator.hpp:74 > #8 0x00007f7048d5d69d in mdds::mtv::soa::detail::iterator_updater<mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>::const_iterator_trait>::~iterator_updater() (this=0x7f703daa9e98) at workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector/soa/./iterator.hpp:55 > #9 0x00007f7048d5d665 in mdds::mtv::soa::detail::const_iterator_base<mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>::const_iterator_trait, mdds::mtv::soa::detail::iterator_base<mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>::iterator_trait> >::~const_iterator_base() (this=0x7f703daa9e98) at workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector/soa/./iterator.hpp:309 > #10 0x00007f704900b9bd in ScValueIterator::GetThis(double&, FormulaError&) (this=0x7f703daaa078, rValue=@0x7f703daaa1f8: -18.819375178914722, rErr=@0x7f703daaa1f6: NONE) at sc/source/core/data/dociter.cxx:141 > #11 0x00007f704900c652 in ScValueIterator::GetNext(double&, FormulaError&) (this=0x7f703daaa078, rValue=@0x7f703daaa1f8: -18.819375178914722, rErr=@0x7f703daaa1f6: NONE) at sc/source/core/data/dociter.cxx:297 > #12 0x00007f70496c3619 in ScInterpreter::ScXor() (this=0x48b93a0) at sc/source/core/tool/interpr1.cxx:1525 with three of them apparently waiting in pthread_mutex_lock but one in pthread_mutex_unlock (and thus presumably making progress). It looks like with a debug-mode libstdc++ these worker threads can easily compete for these listdc++-internal debug-mode mutices. And execution of --enable-dbgutil CppunitTest_sc_opencl_test on my Linux laptop under load easily took 35 minutes, so it looks plausible that that unit test was just too big. While splitting it in two (arbitrarily taking the first and second half of the CPPUNIT_TEST list), use the opportunity to drop the redundant "_test" from the two new target names CppunitTest_sc_opencl-1 and CppunitTest_sc_opencl-2. Change-Id: I9b8f148db667ff9bbf1aacdcaf150e5cb9b8ae87 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146252 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-27Remove Solaris 32-bit SPARC and x86 C++ UNO bridge implementationsStephan Bergmann
As discussed in the mailing list thread starting at <https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html> "Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)", the bridge implementations at bridges/source/cpp_uno/gcc3_solaris_intel and bridges/source/cpp_uno/gcc3_solaris_sparc are apparently dead and should thus be removed. Those were the only bridge implementations for Solaris, but the referenced thread mentions that there are recent builds for OpenIndiana x86-64 (however they are done; presumably using bridges/source/cpp_uno/gcc3_linux_x86-64), so keep general support for Solaris intact for now. Change-Id: I09ec098f5509f25a126342536745509bbe9faaac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146059 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-27Remove support for 32-bit S390Stephan Bergmann
As discussed in the mailing list thread starting at <https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html> "Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)", the bridge implementation at bridges/source/cpp_uno/gcc3_linux_s390 is apparently dead and should thus be removed. However, that was the only bridge implementation for 32-bit S390, which implies that support for the 32-bit S390 architecture as a whole is dead and should thus be removed. Change-Id: I18b3b4fa11df4ce693107bad6bbea2fab1c19f26 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146058 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-27Remove support for AIXStephan Bergmann
As discussed in the mailing list thread starting at <https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html> "Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)", the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is apparently dead and should thus be removed. However, that was the only bridge implementation for AIX, which implies that support for the AIX platform as a whole is dead and should thus be removed. Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-26no need for sd::ModuleController to load these factories via UNONoel Grandin
Change-Id: I2ac1d29ff9cbd5c8676dc1957a62ea02454d052e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146122 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-24[API CHANGE] remove service sd::framework::ModuleControllerNoel Grandin
It makes no sense to be constructed externally. Change-Id: I7e756e225e7b6e1785194b2f73edd5a7d65ec0e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146056 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-24Clarify commentTor Lillqvist
Change-Id: I33d10ea4f3ca35619d6f857d18b5c53a22d822a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146097 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2023-01-24Use PYTHONWARNINGS=ignore instead of 'default' for EmscriptenTor Lillqvist
The Emscripten compiler, emcc is a Python script that wraps the actual compiler. It outputs annoying warnings like .../emscripten/tools/building.py:638: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/emscripten_temp_0fvvg__1/conftest.js.jso.js' mode='w' encoding='utf-8'> to stderr. (Ditto for em++.) Some steps in typical configure script think that a non-empty stderr means there was a problem in compiling a test program. This happens even for a microscopic test program with an option like -Werror which surely *is* supported. Avoid this by setting PYTHONWARNINGS=ignore. Change-Id: I11927fc7dccaa65a239ba65dfc7c6bb7487bf12d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146070 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2023-01-24[API CHANGE] remove service sd::framework::ConfigurationControllerNoel Grandin
It makes no sense to be constructed externally. Change-Id: I6fb8f58ff8594c58d190f78e6f26b2703046a95b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146001 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-23Bin line that was commented-out in December 2021Tor Lillqvist
Change-Id: Ie6c6891d1a682d57e4606454fb6b295072e57644 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146038 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2023-01-23[API CHANGE] sd::frame::Configuration does not need to be an UNO serviceNoel Grandin
It does not ever appear to have been used as such, and it makes no sense to be constructed externally. Change-Id: Ia1a0cccdaeb19ded1197ad8aae701ac86dd3bb48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145989 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-21move presenter console from sdext/ to sd/Noel Grandin
It really wants to part of the main sd UI where it can interact nicely with the existing logic, instead of using awkward UNO APIs. Change-Id: I6e0d486275515d48abe3438b88d4f58d4bee58fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145913 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-20New loplugin:unoaggregationStephan Bergmann
"Find classes that derive from css::uno::XAggregation, but which implement queryInterface in violation of the protocol laid out in the documentation at udkapi/com/sun/star/uno/XAggregation.idl (which implies that such a class either doesn't actually make use of the deprecated XAggregation mechanism, which should thus be removed from that class hierarchy, or that its implementation of queryInterface needs to be fixed)." (compilerplugins/clang/unoaggregation.cxx) The basesHaveOnlyPureQueryInterface check in compilerplugins/clang/unoaggregation.cxx is "a crude approximation (but which appears to work OK)" to filter out any queryInterface base implementations of class hierarchies supporting XAggregation (i.e., cppu::OWeakAggObject::queryInterface). It only fails for the odd ChartDocumentWrapper::queryInterface, which manually implements the XAggregation functionality rather than (indirectly) deriving from OWeakAggObject. But changing that manual implementation looks tricky, so leave that alone for now and add a loplugin warning suppression there, and leave proper clean up for later. Change-Id: Ib16e26237bd703e60b0d9cb7134cb39840842d54 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145912 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-20[API CHANGE] remove unused SlideSorterServiceNoel Grandin
which was introduced in commit 8c4d7aa42dd4b3b08c3b4a9e4ba772737b7bd0c4 Author: Kurt Zenker <kz@openoffice.org> Date: Thu Apr 3 13:42:43 2008 +0000 INTEGRATION: CWS presenterview (1.1.2); FILE ADDED but does not appear to have ever been actually used. Change-Id: Icd33f81cfee246fe72a4b9e584f7a6ca96d6e38b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145907 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-20[API CHANGE] PresenterTextView UNO service is deadNoel Grandin
Nothing constructs it, and it looks like it was never fully hooked up, various bits of it have been removed, starting with commit a38cbc58bbe3b385830a5287ea272e28a8ae3652 Author: Felix Zhang <fezhang@suse.com> Date: Mon Oct 24 17:50:01 2011 +0800 remove unused methods from sdext:presenter Change-Id: I61080fa589ab6b886b841d7be5eed892c4bd829a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145898 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-20[API CHANGE] no need to load PresentationFactoryProvider via UNO and/or configNoel Grandin
there is no benefit to having this constructed in such a convoluted manner Change-Id: Ib02b4bfe689326784bd8233003d10960700811d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145778 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-17Adapt for --enable-wasm-exceptionsTor Lillqvist
Actually, it seems that to build core with --fwasm-exceptions for use in a LibreOffice Technology -using WASM executable, you need to compile *everything* with that (i.e. *all* of core's externals). Just these gbuild things are not enough to ensure that. You have to put CC=emcc -pthread -fwasm-exceptions -s SUPPORT_LONGJMP=wasm CXX=em++ -pthread -fwasm-exceptions -s SUPPORT_LONGJMP=wasm into your autogen.input. Change-Id: I10d21ad0f73e7e5d72864864d595077bd770f4f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145646 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2023-01-14ooo_vba_VBAToOOEventDesc_get_implementation appears twiceCaolán McNamara
Change-Id: Ic11d112b92d0942a4246e80e4da8ca1065fd12c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145521 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-01-14com_sun_star_comp_chart2_ChartDocumentWrapper_get_implementation appears twiceCaolán McNamara
Change-Id: If413be43e68af71ce4f2d1f8e43e4c0d0a5bdc2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145520 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-01-14EXCEPTIONS_ON has no meaningTor Lillqvist
Change-Id: I0ca0dcb76d342b451879788b57da03fb7d79e699 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145456 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2023-01-12introduce docmodel comp., model::ThemeColor, use it in SvxColorItemTomaž Vajngerl
Added a new component docmodel, that has the document model types, which only depend on other basic components. This is needed so the types can be used in every relevant component - xmloff, oox, svx, editeng,... Introduces model::ThemeColor, which is a class used to store the theme color data, including transformations (svx::Transformation). For UNO use XThemeColor is added, and the implementation UnoThemeColor which wraps svx::ThemeColor, so it can be tranported around. Reactor all the code and tests to accomodate for this change. Change-Id: I7ce6752cdfaf5e4d3b8e4d90314afa469dd65cfc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144847 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-12merge duplicate CairoTextRender implsCaolán McNamara
drop getSurfaceOffset because both impls just set these to 0, so its a no opt Change-Id: Ie4f28d57fb8a170c7a46d3cafceef3e049c26e2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145325 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-01-11Use gb_EMSCRIPTEN_QTDEFS only when building with Qt5Tor Lillqvist
Move -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE to gb_EMSCRIPTEN_CPPFLAGS. Change-Id: I435a8482e9d04d9c8218926865738397e2897109 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145354 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2023-01-10OAccessibleImplementationAccess was apparently effectively unused by nowStephan Bergmann
...as there were no calls to its OAccessibleImplementationAccess::getUnoTunnelId so no code apparently made use of that XUnoTunnel Change-Id: I35d392999f1c28e81f7ff4bf395f63642eb17bce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145250 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-06Merge comphelper::OAccessibleContextHelper into ↵Stephan Bergmann
comphelper::OCommonAccessibleComponent Change-Id: I586ae8fe2842fd879ae2ae506c659d06dda16843 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145160 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-03More verbose unoidl-check errorsStephan Bergmann
Change-Id: Ie9aa57c5fca730c7874a527cbe5a0d463a67a0e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144930 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-01sw: read theme from OOXML file and set it to the draw pageTomaž Vajngerl
This change extends writerfilter to use oox::ThemeFragmentHandler to read the theme properties, and sets that to the one and only draw page of a Writer document. This change also removes ThemeTable and replaces it with the ThemeHandler, which takes theme font data from svx::Theme instead. In addition, a test has been writen, which loads a document with a theme, and asserts the draw page has the theme and the theme properties currently supported. Change-Id: Iff0048cd21ea030ac55287707852acc463ec3cb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143699 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31tdf#136604: Remove Source Sans Pro fontsKhaled Hosny
Templates using the fonts are left unchanged. Change-Id: I5ed21155ddd5038eb91f6ad6bcbd7f27f2478638 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143665 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com>
2022-12-28Introduce lo_get_app_data_dir() for Emscripten, tooTor Lillqvist
And not just Android. Hardcoded to return "/instdir" to match what is in the emscripten_fs_image. Change-Id: I26d4ec5e02ec9900e35ca47f1565a13ad2b723b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144849 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2022-12-23Don't use symlinks for the Emscripten soffice.data and soffice.data.js.metadataTor Lillqvist
Symlinks just complicate things. Disk space is cheap. soffice.data is under 100 megs even with Qt5. Note that after this you will need to clean out the existing soffice.data and soffice.data.js.metadata symlinks before you run make, otherwise you will get errors. As such, it is a bit weird that we unconditionally play around with soffice.data for *all* (non-CppunitTest) Executable targets. (Thus, for instance also for vcldemo and unoidl-read.) We should do this dance only for the soffice executable. And we should reduce the number of executables we build for Emscripten. Probably none other than soffice itself makes sense? Change-Id: I75f6719b92d83e88bf59d65c38aeeab47e0b29e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144781 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2022-12-23Un-confuse Emscripten and Qt5 conditionalsTor Lillqvist
The embedded file system that we construct when building for Emscripten is not related to whether we use Qt5 or not. Change-Id: Ibf65cae06093d9130a19780c1116f8b9997c664b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144780 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2022-12-22gb_LTOFLAGS: use -flto=jobserver instead of fixed $(PARALLELISM)Christian Lohmaier
fixed PARALLELISM causes explosion of jobs, especially when machines wtih many cores/threads. A make wtih PARALLELISM=16 would launch up to 16 linker invocations that by themselves would also do their linking with a parallelism of 16, causing load of over 100 and very likely exhausting all memory bringing the system to a crawl or cause OOM kills. for a command to be able to communicate with make's jobserver, it must be part of a submake called with $(MAKE) or the command from the rule needs to be prefixed with the + character. While our gbuild stuff is a submake call, it only is that submake that uses the PARALLELISM flags determined by configure, so that is not sufficient for jobserver usage by the the lto linker. Change-Id: I46ec4760c1a8623195700b8cb16f7deafeb1111e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144593 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2022-12-21tdf#140215 Simplify the handling of .ulf filesIlmari Lauhakangas
Now the headings in the ulf files for .desktop files are in the form [filename_Key] Gallery names are also adjusted to fit the new scheme, where there is no longer a need to pass a --key argument to desktop-translate.py Sync comments with .desktop files and the remaining .ulf and remove obsolete Mandriva Linux meta data while at it. Script to mass-replace relevant names in translations will be provided to infra. Change-Id: I87e8028aa5b66f5f5560efa62ddd9b1e5b61c49c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138455 Tested-by: Jenkins Reviewed-by: Sophie Gautier <sophi@libreoffice.org> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2022-12-20tdf#151341 Use lzfse compression instead of bzip2Patrick Luby
Several users reported that copying the LibreOffice.app package in the Finder from a .dmg file compressed with lzfse compression copies the package several times faster than from a .dmg compressed with bzip2 compression. On a mid-2015 Intel MacBook Pro running macOS, copying in the Finder was at least 5 times faster with lzfse than with bzip2. Also, the hdiutil man page as of macOS Monterey 12.6.2 has marked bzip2 as deprecated. lzfse is marked as supported since macOS El Capitan 10.11 so this change appears safe. The one thing that bzip2 has is better compression so a .dmg with bzip2 should be smaller than with lzfse. A .dmg built from a debug build was 262M with bzip2 and 273MB for lzfse. So it appears that lzfse creates .dmg files that are only 4% or 5% larger than bzip2. Change-Id: I61e2a08cede19a5bb8c257d4fa4762168a3a9dc3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144342 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
generated by cgit (git 2.34.1) at 2025-03-13 08:57:30 +0000