ColorIconView only passed the Color to its activation handler, so its
users took everything else (color name, position for the theme palette
lookup) from the selected item. For mouse and keyboard the activated
item is always the selected one, but the AT-SPI "activate" action of an
item activates it without selecting it first, so the color of the
selected item was applied instead of the activated one.
Pass the index of the activated item to the handler and let the users
take color, name and theme index from it.
Change-Id: I900278bf68e5038e5588ce71b03cd4b5ae9f8918
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211237
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Qt plugin automatically orders buttons for each platform based on
the button's role, which we derive from the Gtk .ui file's
action-widget response code. But to do that conversion from response
code to Qt button role, we need a standard response.
Without a standard response, the button has no role, and gets ordered
to the right of OK/Cancel buttons on Mac. With the correct role, it
is correctly placed far-left along with the Help button.
Change-Id: I16d3126d4999649e7aa6e72ec5e7b1a25f48c2a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210223
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
Tools > Options > LibreOffice > Accessibility > High Contrast
has three possible values. Changing this setting requires a
restart to take effect, but no restart dialog was shown.
Add a new RESTART_REASON_HIGH_CONTRAST reason and wire it up
in SvxAccessibilityOptionsTabPage::FillItemSet() following the
same pattern used for Skia and Threaded Calculation settings.
Also call save_value() in Reset() so that
get_value_changed_from_saved() correctly detects whether the
user actually changed the combo-box value before showing the
dialog.
Change-Id: I1d628ce04bc8f7cf6f1b4e4a8bb7a44a0a653c0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208996
Reviewed-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
Tested-by: Hossein <hossein@libreoffice.org>
This comment just repeats the mapping that the code
underneath it implements.
Drop it, to deduplicate this.
Change-Id: I60497fbd52b057986f76b88cef82d4a991927c7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208600
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This vector can be passed by const reference. Also use
an "r" prefix; this is not a pointer.
Change-Id: I5c96a3701a24096a045c58a99d81ad6b49145c4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208599
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The SvtViewOptions class is used to store the state
of windows/dialogs.
So far, SvtViewOptions::SetWindowState and
SvtViewOptions::GetWindowState are string-based
and the callers are responsible for (de)serializing
the vcl::WindowData to/from string.
This will be changed to become the responsibility
of SvtViewOptions in an upcoming commit.
Since unotools is below vcl in the module
dependency chain, it cannot make use of vcl,
i.e. vcl::WindowData couldn't be used there.
Therefore, move SvtViewOptions from unotools
to svtools, which is above vcl in the module
dependencies.
(svtools/README.md summarizes the purpose of the
module as "Tools on the Top of VCL", which seems
an appropriate place for helper code to manage
the state/options for dialogs, tab pages,...)
Change-Id: If849224c35c7ac895659ddb7c17e6d17061d61a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208124
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
`nCnt` starts with a value of 0 and is incremented
`nEntries` times (unless there is an early return
in the loop, in which case the value is irrelevant).
That means that the value of `nCnt` is the same
as `nEntries` after the loop.
Just use `nEntries` directly and drop `nCnt` to
simplify this.
Change-Id: If9667875cc2b8bffb421cbf78badd404080e8d71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207963
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use the usual "m_" prefix for class members to
distinguish them from local variables.
Change-Id: I9194e72223df84c8fbd896b8b6f93baa3de8b185
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207962
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Instead of passing `this` as the first param in
all callers, convert the static helper into a
class method and drop the extra param.
Change-Id: I4141c1eac68e483f520db880f435c4b64efe8e4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207960
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
SvxLinguTabPage::FillItemSet basically implements
the same logic 4 times, just using a different
table + service name each time.
Extract logic to a new helper method and pass
those as parameters.
Change-Id: If929ee97be7da38de55c735104e5ce296f03a4b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207959
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use the usual "m_" prefix for class member names,
to distinguish them from local variables.
Change-Id: Ieec720a8420ba11bac20915bcf2a15a2722223d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207957
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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>
Use OfaLanguagesTabPage::m_xDatePatternsED instead of the
callback param, as the callback is only connected
for that member.
This prepares for an upcoming commit that will
change the callback param to weld::TextWidget& to
unify/deduplicate the weld::Entry and weld::TextView
implementations.
Change-Id: I186e6f1958d744c78e3ba60fd5fc6f56633407b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207935
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Rename weld::TreeView::connect_column_clicked
and weld::TreeView::signal_column_clicked to make
clear that they are not about a click anywhere in a
column, but about the column *header* being clicked.
The GTK 4 doc for the corresponding
GtkTreeViewColumn::clicked signal [1] by which the API
was apparently inspired is clear about this:
> Emitted when the column’s header has been clicked.
[1] https://docs.gtk.org/gtk4/signal.TreeViewColumn.clicked.html
Change-Id: I0b4b337b5ca938bb1526d9857ed2b0b244daf23c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207591
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Colors were introduced as ThemeColors since they are not entirely application
colors (but also not really UI-related) and because svtools:: is not accessiblke
in vcl. This patch makes the colors hard-coded therefore, still allowing to
disable it but only via expert setting NotebookbarColorTransparency.
It also enables the colors on macOS following the positive feedback.
Change-Id: Iece63d440349b0c42ea6dbc1dad36f0b1e7120a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207476
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Update comment according the the refactor/rename done in
commit 7cc0abf8c4
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Feb 21 17:42:54 2025 +0100
cui: Simplify and rename SvxLinguTabPage::HideGroups
Change-Id: I33304c4ad495aaaede607672318b9e694f8ae41b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207313
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Similar to previous
Change-Id: I9dcf3911ed252902df0a89adde73f8ce466ea6ca
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jun 24 17:27:55 2026 +0200
tdf#130857 Simplify toggle button handling in Java options page
, simplify the handling of toggle buttons in the treeview
also for the "Fonts" option page.
The special toggle button column at index -1, enabled
by the call to weld::TreeView::enable_toggle_columns
isn't actually used, so drop that call and the corresponding
renderer and model columns in the .ui file.
Before
Change-Id: Ic5bbe4ab71ba255ba16bb0a9176ee4c3a8827fe8
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jun 24 16:36:20 2026 +0200
tdf#130857 gtk weld: Don't interpret toggle renderer by itself as expander col
, a single toggle renderer in the first column would
have been interpreted as enabling the special expander toggle
column feature for the gtk3 implementation and thus it couldn't
have been used for the weld API column index 0, but that is
possible now without requiring another dummy renderer in the .ui file.
Change-Id: I2a4cb2b1b41ae341c6a559598a2e4f416e9b0fde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207257
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As outlined in previous commit
Change-Id: Ic5bbe4ab71ba255ba16bb0a9176ee4c3a8827fe8
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jun 24 16:36:20 2026 +0200
tdf#130857 gtk weld: Don't interpret toggle renderer by itself as expander col
:
> This will be used in upcoming commits to simplify/streamline
> existing UI like the one in the Java options page
> (SvxJavaOptionsPage) where the .ui file
> (cui/uiconfig/ui/optadvancedpage.ui) contains
> two toggle renderers in the first column, but only
> one of them is actually used and the implementation
> in SvxJavaOptionsPage only makes use of column indices
> -1 (for the special toggle column), 1 (for the "Vendor"
> column) and 2 (for the "Version" column) and the
> other renderer is not used in practice.
> Presumably, the special toggle button feature was only
> used because using it was mandatory in the past to be
> able to use radio buttons at all.
> That is no longer the case since
>
> Change-Id: I098feb474162d61c5452c3496293a420118e2f4f
> Author: Michael Weghorn <m.weghorn@posteo.de>
> Date: Wed Jun 24 15:42:40 2026 +0200
>
> tdf#130857 weld: Have separate method to set treeview toggle button type
>
> , so move forward with the intention to make the whole
> mapping between cell renderers in the .ui file, columns
> in the .ui file and column indices in the weld API
> more straightforward/less confusing
> (e.g. by being able to drop renderers in the .ui file
> that have no actual equivalent in the implementation
> of the UI using the treeview).
Drop the extra toggle renderer, stop calling
weld::TreeView::enable_toggle_columns and and use a column
index of 0 for the first column instead of the special
index of -1 for the "expander toggle column" that was
previously enabled using weld::TreeView::enable_toggle_columns.
(The use of toggle buttons is now solely enabled by
calling
weld::TreeView::set_toggle_button_type(weld::ColumnToggleType::Radio),
so the call to weld::TreeView::enable_toggle_columns is no longer
needed for that.
Dropping the extra toggle renderer from the first column
also avoids triggering the
"Using the same role multiple times in one column is not supported"
assert in QtBuilder::enableTreeViewColumnDataRole
previously seen when experimenting with adding support for this
Java options dialog for native widgets with the qt6 vcl plugin.
The dialog tab page can be triggered like this:
* "Tools" -> "Options"
* "LibreOfficeDev" -> "Advanced"
Change-Id: I9dcf3911ed252902df0a89adde73f8ce466ea6ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207255
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, weld::TreeView::enable_toggle_buttons was doing
two things:
* enable a special "toggle button column" to be accessed
with a special column index of -1 in the weld::TreeView
API (as documented)
* switch the type of *all* toggle buttons used in all cells/columns
of the TreeView to the type passed as a parameter
(not only set the type of the toggle buttons for the
special toggle button column at index -1)
Untangle these 2 things by splitting this to two methods:
* weld::TreeView::enable_toggle_buttons now only enables
the special toggle button column at index -1.
* The new weld::TreeView::set_toggle_button_type sets
the type of all toggle buttons used in the table.
This makes the API clearer and will allow using one of the
two without necessarily also using the other, which will
allow further simplification/improvements in upcoming
commits.
It could also make it easier to support only setting
the type of single columns to use radio buttons in the
future (i.e. have one column using radio buttons and
another one using check buttons in the same table), but
that would require further rework in the underlying
toolkit-specific implementations (in particular the vcl one).
One case where mixing the two things together results
in non-optimal behavior is the "Assign Styles" dialog
with the vcl implementation:
While the special toggle column with index -1 isn't
actually used, the SwAddStylesDlg_Impl ctor still
calls weld::TreeView::enable_toggle_buttons, presumably
only to enable the use of radio buttons for the actually
used toggle columns at the end.
As a consequence, the style names in the first column
are indented for no good reason (but only to leave space
for drawing the toggle buttons for the special toggle
button column that was enabled without actually being
needed).
This will be adjusted in an upcoming commit.
Initially, just replace all callers of
weld::TreeView::enable_toggle_buttons passing
weld::ColumnToggleType::Radio for the type with
calls to both methods, to keep the existing behavior
and be able to further look into further improvements
separately.
Change-Id: I098feb474162d61c5452c3496293a420118e2f4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207250
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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 reverts commit e20d2de783
* DeepL is just one platform, and not open
* The function requires an account
* Implementation is experimental and not maintained
* Better solution via extension exists
* Decision to revert made at ESC on 2026/Jun/11
Change-Id: I74974671b1fbed6b3299f3532bd6f9263d65927f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206367
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Set the parent for the file dialog that can be used to
select the certificate manager executable in the "Security"
tab page of the options dialog.
Without this, the dialog is not properly modal on top of the
options dialog at least with gtk3 and qt6 with native widgets in
use (SAL_VCL_QT_USE_WELDED_WIDGETS=1), see also mention in
previous commit
Change-Id: Ie02510e0a2a008ab94a89e668def2c4964e481db
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jun 11 10:58:05 2026 +0200
tdf#130857 qt weld: Support "Security" options tab page
. The dialog can be triggered like this:
* start Writer
* "Tools" -> "Options"
* "LibreOfficeDev" -> "Security"
* press the "Browse..." button in the "GPG Certificate Manager"
section
Change-Id: I67276b62b4c63181317c603feca986bf43553804
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206379
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Similar to
Change-Id: Ib6676629433d6df56367320ddcc721ee62f2434f
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 5 11:48:54 2026 +0200
tdf#130857 Port ColorWindow from SvxColorValueSet to ColorIconView
, port another user of SvxColorValueSet to
ColorIconView to improve consistency with other
(native) platform/toolkit widgets and reduce the
use of custom logic.
UI can be triggered like this:
* start Writer
* "Tools" -> "Options"
* go to "Charts" -> "Default Colors"
The ColorIconView now gets newly used in the
"Color Table" section of that tab page.
Adjust the corresponding UI test accordingly.
Change-Id: Ib4f5c7bcf7d6cf01e802c1e57aab1fa938e105b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206222
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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
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: I34876c5bef75e30e758029b0fe5afeecc92d509d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205903
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header and
source file, 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: I91bae842e5b18a83db45de12150c21f75e537fb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205900
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.
Adjust includes in files that were implicitly depending
on transitive includes that are no longer present because
the more specific include/weld/Container.hxx is included
further down now instead of include/weld/weld.hxx.
Change-Id: I04e6bb72ce446b746dfdf88b45c7df9d0ccda473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205899
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: 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: I0cc1e0f3aa60d3457af0f0f30ec8fe74cb5ce6a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205489
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: Ia7bc570fcd463d9adcbcdad070250cec5bc3b949
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205488
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: I2eb564b2483b052f01d4af55fd4feb00b5ed6031
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205472
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Shades the background of Notebookbars with module-specific
colors if theming is enabled. The patch adds four *NOTEBOOKBARCOLOR
colors in the UI theming section.
To deal with light/dark system themes, the color is merged with the
background at a transparency of 150 by default, which can be changed
via the expert setting common::Misc::NotebookbarColorTransparency.
MacOS is excluded since it draws the whole Notebookbar and has
no extra colors for the background.
Change-Id: Ia016499a9657793ebcbe07f7a50281195ab08c43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205153
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
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>
-Using positive phrase "Apply system input language to new text".
-Inverted the checkbox logic in the UI to match the phrase.
-Renamed UI to reflect positive phrase (useinputlanguage)
-Updated tooltip to describe the behavior.
Co-authored-by: Isha Desai <2020.isha.desai@ves.ac.in>
Change-Id: Ib443e86671e1defc7e49ae3a5fed2aef8dc5ecda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203205
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
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>
Rename methods and field related to signalling activation
of a weld::TreeView row to use the same names as the equivalent
ones for signalling activation of an entry in weld::IconView:
* weld::TreeView::m_aRowActivatedHdl -> weld::TreeView::m_aItemActivatedHdl
* weld::TreeView::signal_row_activated -> weld::TreeView::signal_item_activated
* weld::TreeView::connect_row_activated -> weld::TreeView::connect_item_activated
This is in preparation of deduplicating the weld::TreeView
and weld::IconView implementations for these by moving them
to the common weld::ItemView base class in an upcoming commit.
Change-Id: I4ca4dec1295c57cea574b68fd41b89c12144c4f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203350
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This is basically the weld::TreeView version of earlier
commit
Change-Id: I8ca62ac32108f01e2055d5ef9301de22eb5b1931
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Apr 8 12:35:25 2026 +0200
weld: Pass activated item in IconView::signal_item_activated
applying an equivalent change for weld::IconView instead
of weld::TreeView. See that commit for more details/background.
For weld::TreeView, the weld::TreeIter refers to
a full row (and columns are handled separately
by a column index in the weld::TreeView API).
As for the above commit:
Initially, leave the logic of the existing signal handlers/callbackes
(in dialog implementations) unchanged. At least some of them
will be simplified in upcoming commits to use the
newly passed weld::TreeIter param directly instead of
determining the current/activated row a different
way.
Change-Id: Ie6a962702d4f7f069b2f7b77a22a78722b2a6408
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203331
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In "Tools" -> "Options" -> "LibreOfficeDev" -> "General",
only allow configuring the use of a native color chooser
dialog when the SalInstance/vcl plugin in use actually
provides one. This matches the logic already implemented
for file dialogs.
Change-Id: I4cedf9fe5d028d111b972797571265c221f0651b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203003
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Zesen Liu