Age | Commit message (Collapse) | Author |
|
Change-Id: I613f78b8327aa62495ce2563944e3277895eac7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136103
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
This patch hides away the file name and the name of the user when the
user tries to open a locked file. This improves privacy, as discussed in
the bug report.
The .ui file for the new dialog box is
`vcl/uiconfig/ui/openlockedquerybox.ui`. The source files
`openlocked.hxx` and `openlocked.cxx` have been changed to implement
the new dialog. The old string template `STR_OPENLOCKED_MSG` has been
deleted to hide away the private data, and a new string template
`STR_OPENLOCKED_HIDDEN_DATA` has been added; the latter will be hidden
inside the expander dialog. Finally, corresponding changes in the
makefiles have been made to let the makefiles know about the UI file.
Change-Id: I3cc9d2f6e2d9bc43857c80662e2a405aacd7fc70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132342
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: Ie50eeb9bcf1670b014ec600b62ef83a4fb27ee59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132330
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Building LO with WASM native EH and Emscripten 3.1.6+, the link
fails with a missing "emscripten_longjmp" symbol. Actually the
old build was simply wrong, because the emscripten_longjmp
function is just used for the Emscripten SjLj and not the native
WASM SjLj implementation. Linking just worked, because the used
libcompiler_rt-wasm-sjlj-mt.a lib was incorrectly providing that
symbol, which 3.1.6 removed.
But since running the NEH build still fails early in the same way
then before in FF nightly 100 and Chrome (= failure in the LO job
scheduler calling Task::UpdateMinPeriod for the "desktop::Desktop
m_firstRunTimer" timer, resulting in a WASM VM "RuntimeError:
indirect call signature mismatch"), there is still no way to know,
if nothing else it missing. The Emscripten / JS EH build still
works without any code changes. And it's not the first call on
a job object that fails...
And unfortunatly, because Qt itself also uses libpng, it also uses
SjLj for error handling, like LO in the image import, so the Qt
build must also be patched to build with "-s SUPPORT_LONGJMP=wasm".
Simply enough to do (see README.wasm.md). LO's configure now
detects that symbol and will bail out on incompatible Qt and LO
build setup.
See https://github.com/emscripten-core/emscripten/issues/16572
Change-Id: I3a1877f3aeb77873906176b9d3cd1ea92973f1f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132139
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I6ba7c7db6c58fde2e7648ccf32b93fc05f5eae65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128620
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I7b3d17431c5acc92ebc593f4f0fae385c944f61b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128727
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ic38a7a0637ab007f12a6046655cb7d36e24fae33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128655
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I13c50ac005e1e990bd185115b6e1717ce2c6bb45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128654
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I1ed26685561fd79d26cc0844faa3dfe4c00d439a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128625
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
We probably want to pre-create the fontconfig cache in the image.
Startup time still is not really worse for me, but YMMV.
Change-Id: I419682339dd6d943753de9043ff82f2fb877b168
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128624
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
There are three posibilites to add files to the image:
- gb_emscripten_fs_image_files to add individual files
- gb_emscripten_fs_image_autoinstall to add files from AutoInstall
- gb_emscripten_fs_image_filelists to add files from a .filelist
Change-Id: If6804e282a37a37ffae1d291d2af8430e60b59d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128598
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Currently includes environment.js for general environment settings
and soffice_args.js for soffice command line flags.
Change-Id: I1166c5a9ae53c56a69b9223c865b4df525d07450
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128590
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This allows to build a complete static LibreOffice on Linux,
except for linked externals. Since LO's static build implies
disabled dynamic loading, one must select one VCL backend to
be compiled in.
See the (large) comment in solenv/gbuild/static.mk trying to
explain, why this implementation was chosen (spoiler: seems
there is no other way) and what is actually implemented.
This will collect all libraries, statics and externals of
executables. If the executable uses components, it will get
linked to all static components. While it works with any
Executable, it just makes sense for soffice.bin, because the
static component map sucks every dependency in, bloating most
other binaries.
In theory on could generate the dependencies based on the list
of used components (see gb_CppunitTest_use_components), then
generate a specific static constructor map, directly include it
in the exe's cxx code and then link the minimal dependencies.
The static LO should build on Linux with:
--enable-customtarget-components
--disable-dynamic-loading
Tested VCL plugin config is:
--disable-gtk3
--disable-gen
--enable-qt5
The partial build support is split into a 2nd patch.
Change-Id: Iafc95752fae9e88095f54a21f1e30a4f080815e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126790
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|