for reproducible builds, the timestams of zip members must not depend on
checkout date or file creation dates, the metadata should be clear of
those effects.
Only timestamps are rewritten since we want custom order/storage options
for open document files / our make rules should already have
deterministic order (or that determinism is just one additional $(sort…)
call away)
Change-Id: I49341cf3252d5ef5c092508c789fd188f21dc8df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207142
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
commit 1c6eb5324d
Date: Sun Dec 7 18:46:28 2025 +0000
tdf#147630 Transform Hyperlink dialog into a standard SfxTabDialog
had introduced cui/uiconfig/ui/hyperlinkdlg.ui for the new
.ui file to be used for the hyperlink dialog
instead of cui/uiconfig/ui/hyperlinkdialog.ui.
However, the logic to make the tab icons available
was still relying on them being extracted from the
otherwise obsolete .ui file.
Change that by defining the icon names in an .hlst
file and adding that to the list of .hlst files
to consider for bitmaps/images in the corresponding
makefile.
This prepares for upcoming commit
Change-Id: I42b2ca3facde4b0338d0e897a06a68c8cb7323f5
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Mar 10 10:51:44 2026 +0100
Don't rely on icons in otherwise unused hyperlinkdialog.ui
(Without this preparatory commit here, icons would no longer
be shown in the "Insert" -> "Hyperlink" dialog after
the above commit any more.)
Change-Id: I42b2ca3facde4b0338d0e897a06a68c8cb7323f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201358
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The idea is to check that all of the class names match a singleton
declared in a component somewhere and that they return an object that
implements the advertised interface. Otherwise the generated getter for
the singleton will fail with a runtime exception.
Change-Id: I1352e7392e33e9182962e6279fcb62cf3b58352a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200056
Reviewed-by: Neil Roberts <bpeeluk@yahoo.co.uk>
Tested-by: Jenkins
This is basically the drag source equivalent of previous
commit
Change-Id: I93c099b82e209efe11f30bbc4f5fa0a6e1fff992
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jul 11 13:47:54 2025 +0200
vcl: Drop logic to create drop target by service name
, see the commit message of that one for more details/background.
Change-Id: If870b340f39bd7fcf6674af3184e2a4c3017310d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187727
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
DropTarget_createInstance, which would have been called
when trying to create a drop target via service name,
calls SalInstance::CreateDropTarget with the default
null `pSysEnv` param.
For all cases except headless mode or when running unit tests,
that calls the platform/VCL-specific SalInstance::ImplCreateDropTarget
overrides, which would unconditionally dereference the
null `pSysEnv`.
Since this logic to create a drop target by service
name is unused, presumably since
commit 031576105c
Author: Jan-Marek Glogowski <glogow@fbihome.de>
Date: Thu Jan 6 14:16:53 2022 +0100
VCL move platform code from mouse.cxx into plugins
... by moving it into ImplCreate(DragSource|DropTarget).
The existing Create* variant now checks for headless mode and the
IsRunningUnitTest flag, before creating the platform variants.
There are two small helpers to initialize either X11 or Ole based
UNO DnD interace implementations.
Unfortunatly Windows requires to move two dtrans header files, but
at least any other changes are minimal.
, drop it altogether.
com::sun::star::datatransfer::dnd.X11DropTarget is a published
UNO service (see offapi/com/sun/star/datatransfer/dnd/X11DropTarget.idl),
so leave the specification in the IDL file around, even if there
is no way to create an instance via external code (macros, extensions).
That's not new with this commit, since the service was
only meant to be supported by the gen VCL plugin on Linux
previously, but then, trying to create an instance would
crash in X11SalInstance::ImplCreateDropTarget due to
dereferencing the null `pSysEnv`.
The XInitialization interface as mentioned in the IDL file:
/** The service expects an instance of
com::sun::star::awt::XDisplayConnection
as the first parameter. The second parameter must be a long
that contains an XWindow window which shall be registered
as drop target.
*/
interface com::sun::star::lang::XInitialization;
hasn't been implemented any more since
commit 30b4c1d787
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jul 4 10:01:23 2025 +0200
gen: Simplify DropTarget init, don't use XInitialization
, but also before then, an XDisplayConnection to pass
as a param to the XInitilization::initialize implementation
couldn't be retrieved via external code, see the
commit message of
commit 7a9108a48e
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jul 4 11:16:24 2025 +0200
vcl: Stop implementing XDisplayConnection
for more details.
The published service com::sun::star::datatransfer::dnd::OleDropTarget
is Windows-specific in its description. Quoting from
offapi/com/sun/star/datatransfer/dnd/OleDropTarget.idl:
/** The service expects a windows window handle. It is passed as unsigned long.
*/
interface com::sun::star::lang::XInitialization;
, while it was also used on macOS internally
before the above-mentioned
031576105c.
The actual Windows implementation has a separate
UNO constructor (see vcl/vclplug_win.component)
and should therefore be unaffected by this change.
If the X11-specific X11DropTarget service were actually
relevant, it should probably be implemented similarly
(specifically for the gen VCL plugin only, without
reintroducing the rest of the logic dropped in this
commit.)
Searches for "com.sun.star.datatransfer.dnd.X11DropTarget"
and "com.sun.star.datatransfer.dnd.OleDropTarget"
in Google and on Ask [1] didn't give any results that would
suggest that these services would actually be used by
existing third party code.
Change-Id: I93c099b82e209efe11f30bbc4f5fa0a6e1fff992
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187726
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
was needed for the 64bit shell extensions in a 32bit build of
LibreOffice, but that was already broken by
ec0a49ecc7 since that not only removed the
ucrt stuff, but also external/msc-externals/Package_msvc_dlls.mk that
would have registered the files to be packaged into the installation
set. So remove that bit for good and do some related cleanup.
Change-Id: I0b963dcf48eb66cb37d3a6bf017c2ee9aa3fbdf8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185566
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Remove/disable hotkeys which brings up certain dialogs - and sometimes these dialogs loses the focus and they disappear but still keep the document waiting for them to close - for wasm app with wasm-accelerators.xcu
TODO for later: better solution would be to have the props that are removed here rather be install:module="..."-conditional in officecfg/registry/data/org/openoffice/Office/Accelerators.xcu
See details: https://gerrit.libreoffice.org/c/core/+/183389/comment/064afee4_47e66b62/
Change-Id: Ia44390fd7682327feb56e944d30a9fd7ff4cbd82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183389
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
In case of wasm build we can have missing default font config
options compared to Linux or other builds. These options are
necessary for the FontConfig lib.
Change-Id: I3e04847f28bdbd28c767793bf5cb4061b7b3a251
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182462
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
There does not seem to be any downside not signing those anymore (the
2007er commit excluding them mentions rebasing, which is no longer
used), and according to tdf#160568 a number of upsides. So lets start
doing it now.
Change-Id: If56a8c94dcbf431b55929142ddcb24a671e93a6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182213
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Issue:
Accelerators-unxwnt file is omitted when window system is different than X11.
This causes LOK to miss the shortcuts which has "install:module="unxwnt"" signature.
This commit adds the required file in linux case.
Change-Id: I4a8425d17a5d95b03a176153506f29a3f393c173
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181204
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
There is no simple "Windows is 10 or newer" check in MSI, with the
Microsoft policy of "you don't need to know real Windows version".
See also https://developercommunity.visualstudio.com/t/detect-a-windows-version-from-msi/412198
The values that MSI sees (e.g. on my Win11) are:
Property(C): VersionNT = 603
Property(C): VersionNT64 = 603
Property(C): WindowsBuild = 9600
So those can't be used for the check. I use the WINMAJORVER that is
read from registry (Software\Microsoft\Windows NT\CurrentVersion).
There is no more need to check and install UCRT; it was dropped.
Change-Id: Ic02d6aeb965e9684bafd4357f969980f77000e73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178049
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
the ShowDonation has already a default value of true via the schema,
so it is enough to override it to false for the macosxsandbox case
similar to how it is done with the Infobar / using the install:module
method
Change-Id: I8f1ea6d3530e66806f66f9f2d2fb16ef0276e460
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177333
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
...that was present in instdir/share/registry/res/registry_en-US.xcd but for
which the underlying instdir/share/registry/*.xcd files are not included in
static/CustomTarget_emscripten_fs_image.mk, so causing
> warn:configmgr:42:1:configmgr/source/xcuparser.cxx:292: unknown component "org.openoffice.Office.PresentationMinimizer" in "file:///instdir/program/../share/registry/res/registry_en-US.xcd"
etc. in the browser console. (This commit just hides those .xcu behind
ENABLE_WASM_STRIP_* for which localizations ended up in
instdir/share/registry/res/registry_en-US.xcd and caused the above warnings. It
does not clean up the mess further. Also note that the list of files to include
in static/CustomTarget_emscripten_fs_image.mk is largely hard-coded, so somewhat
guessing at the right ENABLE_WASM_STRIP_* to use here.)
Change-Id: I1781f5cb530fe251e63bcad456c2ab1735cf1b3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163852
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...for which the underlying .xcd files are not included in
static/CustomTarget_emscripten_fs_image.mk, so causing
> warn:configmgr:42:1:configmgr/source/xcuparser.cxx:904: ignoring modify of unknown set member node "StarOffice XML (Base)" in "file:///instdir/program/../share/registry/res/fcfg_langpack_en-US.xcd"
etc. in the browser console. (Though note that the list of files to include in
static/CustomTarget_emscripten_fs_image.mk is largely hard-coded, so somewhat
guessing at the right ENABLE_WASM_STRIP_* to use here.)
Change-Id: If3d506514ccdbacb7e64cf62b08093831640c572
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163829
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Otherwise, doing 'make' with --enable-windows-build-signing
fails with
ERROR: SignTool Error: The file is being used by another process.
SignTool Error: An error occurred while attempting to sign: C:/cygwin64/home/buildslave/r/instdir/program/Argon2OptDll.dll
make[1]: *** [C:/cygwin64/home/buildslave/source/libo-core/postprocess/CustomTarget_signing.mk:31: C:/cygwin64/home/buildslave/r/workdir/CustomTarget/postprocess/signing/signing.done] Error 1
make: *** [Makefile:289: build] Error 2
Change-Id: I9d0793f3e42577a47b92025d5670caa44fbd912e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161388
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reason for revert: See discussion in https://gerrit.libreoffice.org/c/core/+/154302
- it's causing CppunitTest_sw_layoutwriter2 to fail on Windows.
- it's causing CppunitTest_sw_layoutwriter to fail on Linux.
- Probably other recent CI failures are also related.
- A similar commit was reverted one year ago for similar reasons -> https://gerrit.libreoffice.org/c/core/+/135859
This commit contains the following commits:
Revert "lok: remove old hack for LanguageTool locales"
This reverts commit 9a5329a266.
Revert "lok: LanguageTool provides list of languages"
This reverts commit 21d0489a5e.
Revert "lok: remove duplicated locales for LanguageTool"
This reverts commit a0865169ab.
Revert "Load the locales from config file for languagetool"
This reverts commit 81b0d9a951.
Change-Id: I3dc48097615f510e33e233e868b6b10704d81e67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154342
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
instead of setting and unsetting the config option at start and exit
because a document that crashes in headless mode leaves my config
in an unwanted built-in file dialog state.
Change-Id: Ib5fcc5994a08c78bffdf57cb5b252dc469167ba2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150126
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
I find with GNU Make 4.3 and find 4.9.0 I get a
workdir/CustomTarget/postprocess/registry/registry_de.list with no
entries, though my libreoffice-7.3 build has a populated one and this
makefile is the same as in that version.
Change-Id: I45ffb381c4c962cd80c3e07e7539d993f86101d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149351
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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>
i.e. when the temporary file is not uses as a responsefile for another
command, but instead the point of running gb_var2file is to have that
file as a result in the end.
also move the helper into the main gbuild.mk and remove Tempfile.mk
Change-Id: I79382bef5d7e8a155ba6a8e0750c6a17da42eb37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143912
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
that parameter did specify how many entries of the list the workaround
method could use to not exceed commandline length limits, so it was a
guess of sorts and many places didn't actually bother with tweaking that
value anyway and just used 100. the $(file …) function doesn't care
about that, so the parameter was always ignored in that case.
Change-Id: If89ec3a1968be297c0fe7c65336c5a965598f0c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143911
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
as that what it actually is and the compiler defines are already
-DMIPS/-DMIPS64 anyway (as are the PLATFORMID and the bridges'
name mips/mips64)
Change-Id: I274e7a3b0e140375a8e697c1790cbdb972251d29
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137489
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: René Engelhard <rene@debian.org>
even when you are a verified non-profit, you still cannot just point to
a donation site/you still would have to offer apple-pay...
the helpmenu one is ugly since it changes the endresult compared to
what is assembled in instdir, but is the least intrusive way for now...
Change-Id: Id348d69371048bdd04d2961cad564fc73f11fd45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137050
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Locales needs to be read again
in the Preferences/Writing Aids section and since
this is a network operation it can cause a problem.
Better to list all the supported locales in the xcu
and load it right away.
Signed-off-by: Mert Tumer <mert.tumer@collabora.com>
Change-Id: Ifff624334627f7be259b677f9b416d6ddedfb2c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135598
Tested-by: Jenkins
I quickly gave up trying to understand what exactly clashes
between the Emscripten macros and OUString templates /
initializers. Not sure it can actually be "fixed".
Also disables the makeshared clang compilerplugin; currently
there is no way to get rid of all the false positive hits
when assigning the std::shared_ptr from a function instead of
a constructor call.
Change-Id: I8b13f179629ea63ff221584030556d2bedadc01b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128604
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...rather than from source component files, so that
<https://gerrit.libreoffice.org/c/core/+/126560> "Allow for conditional parts of
component files" (which adds further processing to the translation from source
to target component files) will also affect the contents of
CustomTarget_postprocess/components's services_constructors.list
Change-Id: Ie5ef42b91b09f5be0d8d512093a6b7e60aee5b50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126644
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...instead of by listing the content somewhat redundantly in the Rdb_*.mk
files, to avoid duplication of logic for components that are only built
conditionally (and thus should only be included conditionally in the
corresponding Rdb). To achieve that, add an "rdb" parameter to
gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros
that internally call gb_ComponentTarget_ComponentTarget), which is used to make
the appropriate gb_Rdb_add_component call internally from within
gb_ComponentTarget_ComponentTarget. (As a special case,
gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that
has already been done by the corresponding gb_Library_set_componentfile call, so
allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to
support that special case.)
Most Rdb_*.mk files are thus mostly empty now. One exception is
i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as
needed during the build in CustomTarget_i18npool/localedata.
1c9a40299d "gbuild: create services.rdb from built
components" had already tried to do something similar (in addition to other
things) under a new --enable-services-rdb-from-build option. However, that
approach had four drawbacks that this approach here addresses (and which thus
partly reverts 1c9a40299d):
1 Rdb_services shall not contain the component files of all libraries that are
built. While that commit filtered out the component files that go into
Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files
that go into others like Rdb_postgresql-sdbc
(connectivity/Rdb_postgresql-sdbc.mk).
2 The code added by that commit to Makefile.gbuild codified the knowledge that
there is an Rdb_services, which is brittle.
3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge
(for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle.
4 Introducing an --enable-services-rdb-from-build option needlessly provided
two different ways how the content of Rdb_services is assembled.
The changes done here would leave --enable-services-rdb-from-build as a
misnomer, as it no longer controls how Rdb_services is assembled. I thus
renamed it to --enable-customtarget-components, as that is apparently what it
still does now.
Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Christian Lohmaier