Previously if the user has configured a language preference in the
config then that choice took precedence over the --language option. It
seems like the --language option is intended for temporary testing of a
language so it would be more useful if it overrode the language choice
in the config.
Change-Id: I30d027b685b9fabda42f40c12599310dfbfc7cfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209982
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Quoting from the QApplication ctor doc [1]:
> All Qt programs automatically support the following command line options:
>
> * -style= style, sets the application GUI style. Possible values depend on
your system configuration. If you compiled Qt with additional styles or
have additional styles as plugins these will be available to the
-style command line option. You can also set the style for all Qt
applications by setting the QT_STYLE_OVERRIDE environment variable.
> * -style style, is the same as listed above.
> * -stylesheet= stylesheet, sets the application styleSheet. The value must
be a path to a file that contains the Style Sheet.
Note: Relative URLs in the Style Sheet file are relative to the
Style Sheet file's path.
> * -stylesheet stylesheet, is the same as listed above.
So far, LibreOffice's command line argument
processing/evaluation would prevent passing these
options as they were considered invalid arguments
for LibreOffice.
Adjust this to simply ignore the "-stylesheet=..."
and "-style=..." variants when validating command
line arguments, and pass these on to the QApplication
in QtInstance::CreateQApplication.
Notes:
* For now, only the single-arg variants using "=" are supported,
i.e. "-style=<somestyle" and "-stylesheet=<somestylesheet>", but
not "-style <somestyle>" or "-stylesheet <mystylesheet>".
The logic could be extended as needed in the future.
* At the point in time that the command line argument processing
happens in LO, the vcl plugin hasn't been created yet, so there
is no good way to tell whether one of the Qt-based vcl plugins
is actually going to be used. Just allow the arguments if one
of them was enabled at build time. If another vcl plugin (e.g. gtk3)
is used, those arguments are simply ignored.
[1] https://doc.qt.io/qt-6/qapplication.html#QApplication
Change-Id: I3a4bf2071eaf875e45bdd9cd5b5f928118412cb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208833
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Drop the exterals patches as VCL internals don’t support this anymore,
and drop the LOK addfont change as it wouldn’t work now. I don’t know if
LOK addfont has any use now, but I left it.
Change-Id: I2798679d0bb59bb6c2c6e0eae329287f36662223
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208546
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
Switch the weld::Entry and weld::TextView handlers
that are called when the text changes due to user
interaction to pass a weld::TextWidget& param
instead of a weld::Entry& and weld::TextView&
one respectively.
Adjust related methods across the code base accordingly.
This unifies the behavior for both of these
weld::TextWidget subclasses and prepares for
deduplicating the logic and moving it to the
common base class in an upcoming commit.
That will also ensure they stay in sync.
(Change also motivated by the fact that their behavior was
differing before
Change-Id: I03d2a13cd84d53d806eb9e363f49c4b6be28d938
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jul 9 13:08:58 2026 +0200
tdf#130857 weld: Don't signal about programmatic TextView text change
.)
Change-Id: I5572fc88caf577fae9a23a39f1ec4f2179935a99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Completes the deprecation of legacy coordinate subsystem naming by
renaming GetOutOffYPixel() and SetOutOffYPixel() to
GetDeviceOriginY() and SetDeviceOriginY() across OutputDevice,
Window, and CoordinateMapper.
This unifies axis naming conventions following previous X-axis
refactoring passes, clarifying that these fields represent the
physical origin offsets of the device rendering canvas.
This patch also moves view transformation logic inline from outdev/map
to CoordinateMapper, and wraps sprawling multi-line logic formulas
across mapping routines to clean up formatting boundaries.
Key changes:
* include/vcl/outdev.hxx / window.hxx: Updated public declarations
to replace GetOutOffYPixel with GetDeviceOriginY.
* vcl/inc/CoordinateMapper.hxx: Migrated view transformation cache State
members and mapping calculation methods into the mapper object.
* Global adjustments: Patched all related coordinate offset reads
and tracking writes throughout desktop, editeng, sc, svx, and vcl.
Change-Id: I28fec54a7f3312cc41ada2de38b26351c0a65527
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203646
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Rename GetOutOffXPixel() and SetOutOffXPixel() to GetDeviceOriginX()
and SetDeviceOriginX() across OutputDevice, Window, and CoordinateMapper.
The legacy "OutOff" naming convention obscured the difference between
system-level window positioning offsets and internal content scrolling
(SetPixelOffset). The new nomenclature explicitly communicates that
these metrics strictly govern the device coordinate space origin.
This patch focuses strictly on the X-axis coordinate reads and cleans
up duplicated formatting signatures inside the CoordinateMapper header.
Impacted modules:
* include/vcl: Update public declarations in outdev.hxx and window.hxx.
* vcl/inc: Clean up CoordinateMapper.hxx whitespace and scaling hooks.
* Global: Patch dependent pixel coordinate reads across desktop, editeng,
sc, sfx2, svx, and vcl.
Change-Id: I546e1d255887e3b280ff15caca2e27ef10de52d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206509
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
Most callers use weld::ColumnToggleType::Check
and only a few use weld::ColumnToggleType::Radio.
Add a default param of weld::ColumnToggleType::Check
and drop the explicit param for callers passing this.
This prepares for moving setting the toggle button
type to a separate method in an upcoming commit to
clarify what it actually does.
(It doesn't only set the toggle button type of the
special "expander toggle column" enabled by
weld::TreeView::enable_toggle_buttons, but of *all*
toggle buttons used in any of the cells of the
whole table.)
Change-Id: I65edb7cd5f79c59222c1c415f118b8adbdec0271
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207249
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This was originally introduced in
commit be0e1382a6
Date: Fri Dec 5 20:22:22 2025 +0000
Collect .ui use coverage information
, presumably for Collabora Online which no longer uses
this repo.
By now,
commit 8a91868e21
Date: Tue Jun 2 14:53:19 2026 +0200
drop JSDialog machinery
dropped the use of the collected information, so
also stop collecting it altogether.
Change-Id: I4a7ac9e8f503c9958133e6cd0a1574bf9347e393
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205938
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when one class changes.
By now, only weld::Button is left in weld.hxx.
Rename the header to Button.hxx.
Drop weld.hxx includes and instead add Button.hxx
includes (or weld::Button forward declarations) where
weld::Button is used.
(Don't simply replace all weld.hxx includes with
Button.hxx ones, since many of them were for the
use of other widgets that have since been moved
to their own headers.)
Add further includes where needed now that the
(direct or transitive) includes of weld.hxx were removed.
Change-Id: I8ea6201446a418d5e38b46337059dcd517ee29d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses,
as well as a few helpers.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when anything in weld.hxx
changes.
Move the weld::toId and weld::fromId helpers from
weld.hxx to weldutils.hxx, in preparation of getting
rid of weld.hxx altogether in an upcomcing commit.
Change-Id: I408fe20a74ff104cbfe07bde3105317a1922ff61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Add missing includes/forward declarations in places
previously depending on transitive includes that
are now dropped.
Change-Id: I3215b358e0fa45ffce08756218c386e1a4d7ebc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205928
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
LOK_HELP_URL, LO_CERTIFICATE_DATABASE_PATH, DEEPL_API_URL
and DEEPL_AUTH_KEY are never used internally
Change-Id: I995768a7ecd4b56b249dee261574e6709cd5f639
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205890
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ide86f35543468a88288a068cc9f89eaf381ac52f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205763
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I6d9323c56bca95734a1b60daa60085547f212a66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205485
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I98a090f31fc8b4111b7e13dfcdf843af8c3113c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205474
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I8861b5494c22b666ed80ead82ec3a8293dbeee81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205473
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: If7cb4403f1861c465f44a1cae4065b0bf8dfad48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205323
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
...as emsdk 5.0.3 deprecated the predefined EMSCRIPTEN macro (see
<https://github.com/emscripten-core/emscripten/commit/506052bd8b4e23ded7f2351c62ca3b24d40c8cf3>
"Warn about usage of deprecated EMSCRIPTEN macro. NFC (#26381)"), causing
failures like
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:29:
> In file included from include/sfx2/viewsh.hxx:35:
> In file included from include/editeng/outliner.hxx:32:
> In file included from include/tools/color.hxx:26:
> include/osl/endian.h:66:15: error: macro 'EMSCRIPTEN' has been marked as deprecated: use __EMSCRIPTEN__ instead [-Werror,-Wdeprecated-pragma]
> 66 | #elif defined EMSCRIPTEN
> | ^
> /home/sberg/emsdk/5.0.4/emsdk/emscripten/main/cache/sysroot/include/emscripten/emscripten.h:35:66: note: macro marked 'deprecated' here
> 35 | #pragma clang deprecated(EMSCRIPTEN, "use __EMSCRIPTEN__ instead")
> | ^
To avoid confusion, also suppress the -D$(OS) in
solenv/gbuild/platform/unxgcc.mk that would unnecessarily keep defining
EMSCRIPTEN.
Change-Id: Ic1f187cf1c6417cd95d4092e9cea01a665bd1b2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/34
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 50291c2ed83bdb49bb827a4a12905d94b8c42035)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch the param for the signal and handlers used when
the selection in a weld::TreeView changes from weld::TreeView&
to the base class, weld::ItemView&.
This is in preparation of moving the logic to the weld::ItemView
base class in an upcoming commit.
Handler implementations that require a weld::TreeView
instance can use the one that the signal is connected
to, e.g. use the class member directly inside of the
implementation instead of using the param (as is done
in most of the places anyway).
Change-Id: I0bbf8fe1dbd95906a5224155d48d832bcd144532
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203366
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
It's only used by that sublcass, so move it there.
Also make it private, as it is internal logic.
Move DialogHelper::IsSharedPkgMgr as well, which is
now also only used by ExtMgrDialog.
Change-Id: Ifaac7e9bdc231d5b26a3184cf6b15d2237d6d734
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200154
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
commit 5a6985c124
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Sat Nov 8 09:42:17 2025 +0100
tdf#169318 extension mgr: Deduplicate close logic
extended TheExtensionManager::Close to also
reset TheExtensionManager::m_xExtMgrDialog, i.e.
delete the extension manager dialog.
That is fine for the callers newly added in the
above commit.
However, for the preexisting case in
ServiceImpl::startExecuteModal, the call to
TheExtensionManager::checkUpdates
a few lines above the call to
TheExtensionManager::Close triggers a separate
update thread that still wants to use the
dialog after it gets closed, causing a crash.
(Can be triggered e.g. by installing older
version 6.3 of the LanguageTool extension [1],
then "Help" -> "Check for Updates", closing
that dialog, then clicking the "Updates for extensions
available" button in the menu bar; requires a build
with --enable-online-update enabled.)
Don't destroy the dialog there, but only close
the dialog itself, by calling weld::Dialog::response
instead.
Make the "destructive" TheExtensionManager::Close
private.
[1] https://extensions.libreoffice.org/en/extensions/show/languagetool
Change-Id: I370b357fe4db435489366afbf1b3003770d6a209
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200151
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Return and use the more specific weld::Dialog
subclass in TheExtensionManager::getDialog
instead of just weld::Window.
Change-Id: I931864f8117af87386761f0838b4f3970d9d8c62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200150
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Andrea Gelmini