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 is similar to
commit 9bfbc7d139
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 19 09:21:36 2026 +0200
tdf#130857 sc: Merge checkbox and text column in "Protect Sheet" dialog
, but for a different dialog. See the above-mentioned
commit for more details/background.
To trigger the dialog:
* download APSO 1.4.2 from [1]
* "Tools" -> "Extensions"
* install the APSO extension via the "Add" button, etc.
* restart LO
* "Tools" -> "Extensions"
* -> "Check for Updates"
This case was found by running the ui-rules-enforcer
with upcoming commit
Change-Id: Ib596c39698d308e18e9ede27c239cd44e43863a9
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 19 08:58:59 2026 +0200
tdf#130857 ui-rules-enforcer: Check that special toggle renderer not by itself
in place.
[1] https://extensions.libreoffice.org/en/extensions/show/apso-alternative-script-organizer-for-python
Change-Id: I065032e4b7f7cfe07ea38639384412584b414127
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207125
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
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>
...instead of using the default -static-libsan, where dynamic libraries must be
built without -z defs and where all executables must link against the static
libsan. Dropping the latter requirement means that we no longer need the static
sal hack in Library_jpipe.
But instead, at runtime, when a process loads any library that links against the
dynamic libsan, then that dynamic libsan must be loaded first into the process.
For executables that are themselves linked against the dynamic libsan, that is
already the case. For scenarios where we invoke a Java executable, we now use
LD_PRELOAD to fulfil that requirement. (And for invocation of Python
executables, this commit assumes a --enable-python=fully-internal configuration,
so that executable will be itself linked against the dynamic libsan.)
Dropping the requirement to build without -z defs revealed that using
-fsanitize=vptr often requires RTTI symbols from libraries that are not usually
linked against. Such cases are now handled by conditionally including those
libraries in gb_*_use_libraries calls. (This could be restricted even further
to only be done under -shared-libsan, but it arguably doesn't hurt to also do it
under the default -static-libsan.)
The expectation is that -shared-libsan will explicitly be passed into the
configuration along with any other -fsanitize... arguments via
--with-extra-cc-flags and --with-extra-cxx-flags. This commit does not yet
remove the code that is only needed for the (default) -static-libsan caes, but
that code could eventually be cleaned up, once all (Clang) builds using
sanitizers use -shared-libsan. (GCC already defaults to a shared model.
Instead of a combined -shared-libsan, it has individual -shared-libasan etc.,
though. This commit does not intend to make any changes to any potential GCC
sanitizer builds; my assumption is that we do not have any such, and that they
wouldn't work out of the box, neither before nor after this change.)
Change-Id: I932e4b75c299c158211e122adf33d7988892a87e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200935
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
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>
Andrea Gelmini