New dialog (Insert > Calculated Field) to add, modify, and delete
calculated fields. Accessible from the menu bar, pivot table context
menu. Insert, modify, delete a calculated field properly.
TODO: maybe more warnings during formula entry edit
Change-Id: Ifdf50de96ff6f7b736b6307e9bea3ae56108679f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200314
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga@collabora.com>
Since
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, add
that .ui file to the list of .ui files to include in the
wasm/emscripten file system image.
This makes the dialog show up for a wasm build
when using "Insert" -> "Hyperlink" in Writer,
instead of triggering a crash/abort.
Change-Id: I589433b4aa22c52b2c6b94cf45933eea6683df20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201359
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
It's unused now after
commit 1c6eb5324d
Date: Sun Dec 7 18:46:28 2025 +0000
tdf#147630 Transform Hyperlink dialog into a standard SfxTabDialog
which instead added the new cui/uiconfig/ui/hyperlinkdlg.ui
Previous 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
also dropped the need to keep the file just to make
the tab icons still available.
Change-Id: If96053d4b242f8ddb6737a6ef128e42fb64d3d57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201352
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
menubar Insert and Data. With that command a new Table Style area (context) can be
added to the sheet with a defalt table style name (Table1, Table2 etc.).
If the default ooxml table styles are available the "TableStyleMedium2"
style will be automatically applied (same as in Mso), which can be modified
to any other available style after that.
Also add new command for delete a table context. It is also available
from Insert and Data menubar.
For simplifying the dbrange behaviour, it will not possible to change DbRange
properties of those DbRanges which has Table context. (same as in MSO)
from the older DbRange dialog
Includes cleanup for unused-but-set variables (-Werror).
Change-Id: I98067e895d9595ba07206759deff6848dc299216
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194408
Tested-by: Balazs Varga <balazs.varga@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Balazs Varga <balazs.varga@collabora.com>
Code-Style: Balazs Varga <balazs.varga@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196768
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197994
Tested-by: Jenkins
...as building against emsdk 3.1.46 now started to fail with
> /home/tdf/lode/jenkins/workspace/lo_gerrit/tb/src_wasm/svx/source/svdraw/svdmrkv.cxx:1231:78: error: no member named 'view' in 'std::stringstream'
> 1231 | handleArrayStr = OString::Concat(", \"handles\":") + aStream.view();
> | ~~~~~~~ ^
> /home/tdf/lode/jenkins/workspace/lo_gerrit/tb/src_wasm/svx/source/svdraw/svdmrkv.cxx:1236:86: error: no member named 'view' in 'std::stringstream'
> 1236 | handleArrayStr += OString::Concat(", \"GluePoints\":") + aStream.view();
> | ~~~~~~~ ^
(<https://ci.libreoffice.org//job/lo_daily_tb_linux_wasm/1251/>) after
47da2ff20e "Avoid some std::string creation".
So just bump to the most recent emsdk version that works out of the box.
Anything newer than emsdk 4.0.10 (like the current emsdk 4.0.20) would currently
fail for us with the issue described at
<https://gerrit.libreoffice.org/c/core/+/188465> "Emscripten: Adapt to internal
emscripten/val.h change in Emscripten 4.0.11", though, so stick with emsdk
4.0.10 for now.
Change-Id: I540569e43454c222424895b1e552b8b07d1d5066
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194331
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Main changes are:
1) new jsontype: `quickfind`
2) send the full json when constructed
3) create new .uno:QuickFind
4) create wrapper and window to register
QuickFindPanel as a DockingWindow so that we
can create it from CreateChildWinow without
going through sidebar
5) Register SID_QUICKFIND as a ChildWindow in
the SwView interface
Signed-off-by: NickWingate <nick.wingate@collabora.com>
Change-Id: I2086316b932c1495b0adee7a062bdbbcb104f1ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188667
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194144
Tested-by: Jenkins
Currently, the connector functionality in Writer is only available after copying such lines from Draw.
This patch adds connector functionality directly to Writer.
This functionality is available in:
1. "Insert" -> "Shape" -> "Connectors" in Standart Toolbar (UI variants)
2. "Insert" -> "Connectors" in Tabbed (UI variants)
Change-Id: I51b517f160a69248458100ebe4fb97695bbfe1d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189911
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Currently, the connector functionality in Calc is only available after copying such lines from Draw.
This patch adds connector functionality directly to Calc.
This functionality is available in:
1. "Insert" -> "Shape" -> "Connectors" in Standart Toolbar (UI variants)
2. "Insert" -> "Connectors" in Tabbed (UI variants)
Change-Id: Icae023bf123e867dbef152789d1a015ea0dfe52d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189266
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
It was introduced specifically for the Start
Center in
commit fb3c3b2861
Author: Caolán McNamara <caolanm@redhat.com>
Date: Mon Oct 19 09:35:00 2020 +0100
add MenuToggleButton for split toggle/menu button
which is uniquely used in the start center
but is no longer used there since
commit 164a1f4c33
Author: Heiko Tietze <tietze.heiko@gmail.com>
Date: Fri Sep 9 16:07:28 2022 +0200
Resolves tdf#80934 - GUI means to filter thumbnails in start center
For use within toolbars, there's GtkMenuToolButton [1]
which seems to provide a similar logic (one button
to toggle, and another small one with an arrow to
open the menu) without having to implement so much
custom logic for the GTK implementation.
[1] https://docs.gtk.org/gtk3/class.MenuToolButton.html
Change-Id: I356c50f95da300a82965710010b41dea7dba6325
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188393
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The scope of this dialog has changed with 98d1ac254bd62dff9d0aa9c72ba879d1d52495ef
and it's not just an UI for the ToolbarMode namespace
* Toolbarmodedlg* renamed to UIPIckerdlg*
* UNO command ToolbarModeUI renamed to UIPicker
* SID_TOOLBAR_MODE_UI renamed to SID_UI_PICKER
Change-Id: Id4d617aeee83ae1800d4b9a2d207d28c391dcdb4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185789
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
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>
Option is for WASM only, so shouldn't be named --with-main-module.
Also the option's default value changed since it was introduced, so the
documentation became outdated. See commits:
fe678ffc6f Emscripten: No need to pass --with-main-module into build configure
437b4d802c Fix default value of Emscripten --with-main-module
8aef8c3a14 Make it possible to run either Writer or Calc in the same Emscripten thing
97ee126d69 WASM add Calc as optional build result, make it build & run
Change-Id: I29aeeb9a840ec07e46cbf153c535b3fca9d88cd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182798
Tested-by: Jenkins
Reviewed-by: Moritz Duge <moritz.duge@allotropia.de>
...i.e., stripping both Calc and Writer, which comes in handy when trying e.g.
-fsanitize=address and the resulting binary would otherwise become too large.
(Which also unearthed that the StartModule/menubar/menubar.xml had erroneously
been added to the Writer section of static/CustomTarget_emscripten_fs_image.mk
ever since 88b94aafc2 "WASM create and link the
Emscripten FS image".)
Change-Id: Ia880040f51f15d33ed447a1c69838fa807f48ade
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181188
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
Instead of Color, we have Light and Dark in the registry. So each theme extension
will specify dark and light color values for each "customizable element" like
DocColor etc. Under appearance we have three radio buttons - light/dark/system. If
system is selected then light/dark colors are switched based on the system's
theme. if explicitly light/dark is selected - that color is used from the
registry.
ColorConfigValue now has three entries nColor, nLightColor, nDarkColor. nColor is
used as a cache for the color being used at the moment. This is to avoid otherwise
expensive function calls + hundreds of modifications in the codebase just to
change nColor. nColor is cached either when the theme is loaded or when changes
are committed in `ColorConfig_Impl::ImplCommit()`.
Now, if Automatic theme is selected then themes is disabled and the application
uses the system colors. If some other scheme is selected like "CustomTheme" etc,
then LibreOffice themes/UI color customization is enabled and the theme colors are
used.
Instead of a scroll window, now we have a combobox for the registry entries and a
single color dropdown to select the color value. This color dropdown is for
convinience in case the user wants to change some specific color that's bothering
him. For themeing, theme extensions should be used.
API CHANGE
+ remove Color in favour of Light and Dark
+ AppBackground has additional two - BackgroundType and Bitmap
+ remove officecfg::Office::Common::Misc::Appearnce in favor of
officecfg::Office::Common::Appearance::ApplicationAppearance
+ move LibreofficeTheme under officecfg::Office::Common::Appearance
UI
+ it looks like https://i.imgur.com/UMxjfuC.png which is a little
different from how the [mockup] on the ticket describes it, and that's
because of lack of time due to upcomming feature freeze.
+ system/light/dark allow the user to switch between light/dark modes
based on either the system theme (system) or by manually specifying
light/dark.
+ ui themeing and color customization is disabled when automatic theme
is selected, and enabled otherwise.
[mockup]: https://bug-attachments.documentfoundation.org/attachment.cgi?id=197469
Change-Id: I1a7f70dfe44b81f863814f87e8d46e146c0e3d5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174835
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Reviewed-by: Sahil Gautam <sahil.gautam.extern@allotropia.de>
- remove ui and source files related to app colors and personalization tabs
- remove persona entries from registry
- remove functions related to persona settings from StyleSettings, vcl..
- remove ui and code related to tools - options - view - appearance combo box
Change-Id: I98f0c38dc1facddd0e8dd03197c61a92287fdbc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176836
Tested-by: Jenkins
Reviewed-by: Sahil Gautam <sahil.gautam.extern@allotropia.de>
...and just unused dummies since 3.1.58, so don't install them for >= 3.1.58,
even if the dummies would still be available for < 3.1.68
Change-Id: Ida55be2fa3b75982bfd764b7b2676e63c092fe79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175822
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
These objects use smart proxies, so Embind adds them to a JS finalizer (in JS
runtimes where FinalizationRegistry is available), so it shouldn't be necessary
to manually .delete() them, but Embind then emits "Embind found a leaked C++
instance..." warnings about them, which clutter the JS console.
While it is probably impractical for client code to manually .delete() all such
instances, we can at least explicitly .delete() those that occur in uno.js
itself.
Change-Id: Ia21ca5f0bdb246cc5ea272599befd9a16bc970a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172661
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
- Add new text Glow effect properties for shapes
- Using TextGlowPrimitive for rendering uniform text glow in shapes
- Add/allow new UI Glow Effect for texts in shapes on sidebar
(Only for Impress/Draw and Calc)
- Import/Export ooxml files with Glow effect on texts in shapes
(Only PPTX/XLSX)
- Import/Export odf files with Glow effect on texts in shapes
- Add unit test for glow text attributes in ODF
- Add uni tests for OOXML import/export
Note: Also this patch effects on
tdf#144061 - Effects: Allow GLOW to apply to Text (as we have for shapes)
Change-Id: I16586c01654f197f532129e4e06aa2ef9f214395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172216
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
...that had been added with f90c68316c "WASM: add
Emscripten demo application". Whatever the original intention, it has probably
served its purpose by now---and now only negatively impacts (re-)build times.
Change-Id: I2bda8d12b91e741c4d0f7d3f02597e0e9505a73a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172087
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...to be used by external code, to mitigate the issue mentioned in the commit
message of cccc983eb3 "Emscripten: Run external
code on LO's main thread": "Alternatively, running external code on the
browser's main thread rather than on LO's main thread could be more ideal in the
sense that the external code would then have access to the browser's document
object."
On the browser main thread, external JS code can now await a Module.uno_main
Promise that provides one port of a MessageChannel. And on the LO main thread,
external JS code has access to the other port of that MessageChannel as
Module.uno_mainPort. (And the external code is completely free in what
onmessage handlers to set up and what form of postMessage calls to use on those
two MessagePorts.)
Change-Id: Iab6bc7676c744eacb70ddd9f3f80f64e9efd1cf1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171907
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...and not the browser's main thread. Those are different threads now since
6e6451ce96 "Emscripten: Move the Qt event loop off
the JS main thread". Running `Module.uno_init.then` on the browser's main
thread would never trigger, as that promise is only resolved on LO's main
thread.
When external code was included in soffice.js via
EMSCRIPTEN_EXTRA_SOFFICE_POST_JS, that didn't make a difference: Emscripten
effectively replicates that code to all the worker threads, so whatever worker
thread resolved the Module.uno_init promise (i.e., the LO main thread) had the
external code available and ran it. But when external code was included
directly in some HTML file (which "manually" provides a canvas and loads
soffice.js, not relying on the qt_soffice.html convenience functionality), it
was available in the browser's main thread but not in LO's main thread. For
that use case, introduce a new Module.uno_scripts array that can be set up in
the HTML file to contain an array of URLs (represented as strings) of scripts to
load into LO's main thread.
(Alternatively, running external code on the browser's main thread rather than
on LO's main thread could be more ideal in the sense that the external code
would then have access to the browser's document object. But, for one, it would
be less ideal in the sense that we would then potentially again execute LO code
(which we call into from the external code via UNO) on the browser's main
thread, which would bring back the issues that
6e6451ce96 "Emscripten: Move the Qt event loop off
the JS main thread" solved. And, for another, when I experimentally tried it
out, it caused massive Qt threading issues, so I quickly gave up again.)
Change-Id: If01a7859751706f168e93ccac75758ae5ce17cd2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171870
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...to have $(WORKDIR)/installation/LibreOffice/emscripten populated with just
the relevant files from $(INSTDIR). (This doesn't reuse the complicated
CustomTarget_instsetoo_native/install used for other PKGFORMATs; as a special
case, it uses a much simpler CustomTarget_instsetoo_native/emscripten-install.)
Change-Id: I9c7509aadbc0e6e49ec95bf51c748c2ff9f778b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171066
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...mostly because the relevant parts of the code are hard-disabled (even if you
would --disable-wasm-strip) with ENABLE_WASM_STRIP_RECOVERYUI=TRUE and
ENABLE_WASM_STRIP_SPLASH=TRUE. (And if there are places in the code that would
need the equivalent of either --norestore or --nologo after all, we could
probably better add explicit #if EMSCRIPTEN there instead.) This allows to get
rid of hard-coding the Qt Emscripten LO command line arguments, which means that
e.g. web applications embedding LO would now be able to specify them themselves.
Change-Id: I8e2dcfd170cc32276bfb9007f098f6ae6a7f9ec1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171063
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...as there can be situations (cf. the newly added test code in embindtest.js)
where objects that need to be deleted are passed as payload of the exception
value to be thrown. So there now is a (mandatory, as Embind doesn't allow to
implicitly pass undefined) third parameter now that must be an array of objects
on which to call .delete().
(75fe059974 "Embind: throwUnoException from JS"
had deliberately made throwUnoException take two arguments, because if it
"directly took a css::uno::Any argument, JS client code would need to create one
with `new Module.uno_Any(...)` and call .delete() on it, but there is no place
where it could call .delete()". There now would be such a place, but it would
probably still be tedious most of the time to explicitly construct a new uno_Any
to pass into throwUnoException both as the exception and in the toDelete array.
So keep that design decision to have throwUnoException take individual type and
value arguments.)
Change-Id: Idec029d9e500457b02d20d899b9a2328cd7a5d7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171024
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
Balazs Varga
