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>
oss-fuzz failed with .../solenv/gbuild/ComponentTarget.mk:53:
*** No LIBFILENAME set at component target:
/work/workdir/ComponentTarget/i18npool/util/i18npool.component.
Stop.
oss-fuzz uses --with-locales=en, so actually include the
i18npool.en.component file in the services.rdb generation.
Regression from commit 1c9a40299d
("gbuild: create services.rdb from built components").
Change-Id: Ica250403b687f636880bbc066e83b9ffe9689c5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126495
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
... and introduce the --enable-services-rdb-from-build option.
Currently the build handles global build options redundant
in a few places:
* in Repository*mk + modules - the "real" build dependencies
* the full services.rdb generation
* the static UNO constructor map generation
Also the component files don't reflect the really built components
and so the RDB services generation must handle the whole options
to select the correct components.
So this optionally replaces the latter two by generating the list
of components and it's constructors from the build itself. As a
consequence, component files must now be split, so they reflect
the real components in the libraries, otherwise the static
constructor list will have missing symbols. IMHO this is more
natural, as it happens in the same place already handling these
build options for the sourcecode.
This also adds a convenience helper to add multiple component
files: gb_Library_set_componentfiles
This is WIP and currently just works for the stripped WASM build,
which introduces many more split component files in later patches.
It also explicitly filters the gb_Rdb__URECOMPONENTS and the
CppunitTest related components from the services.rdb. Maybe there
is a good way to do this properly.
Change-Id: I1b38a6f2c1e5221f18d7e5e756c30263b555d962
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126185
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Caolán McNamara