No Functional Change intended
This function is used very specifically for only UI stuff.
It is very different from any regular stuff.
So help to differentiate it by requiring the bool value.
To make sure I got all of them, I tested by requiring
a bogus OUString variable as well - make sure it compiled.
Change-Id: I4879427a806324d9fb9c033ef6b66ad24ba0bd54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208234
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
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>
Adds copy and paste buttons to the Macro Manager dialog so that script
files can be copied with script providers that support the
XCopyableBrowseNode interface. The “copy” button selects the file to be
copied and then the “paste” button works when a destination is selected.
Change-Id: I058b7ed53c837d17723b5f1b4e69f0bc7ae2594f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207738
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Implementations of XBrowseNode have a bunch of extra methods which are
accessed by using XPropertySet::getPropertyValue to determine if the
action is possible and then XInvocation::invoke to invoke it. This patch
adds wrappers around checking and invoking these methods. The idea is to
abstract away the actual implementation so that the approach can be
changed in a later patch.
Change-Id: I117ab848391dbb1277f9331d6a93f71c2cb556ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207343
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
`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
Commit result of running
for a in `git ls-files "*.ui"`; do bin/ui-rules-enforcer.py $a; done
Change-Id: Ib41d60aa8ba3f81fe781fac0761e454be8b47ca2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207791
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch the order in which the widgets in the .ui file
are defined so that the order better matches the visual appearance
and logical order, which makes sure that tab focus order with the
Qt-based VCL plugins is correct as well when using native Qt
widgets (SAL_VCL_QT_USE_WELDED_WIDGETS=1), where
focus order is (by default) based on widget creation order.
See
commit 02692566ad
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Oct 24 17:43:35 2024 +0200
tdf#130857 optnewdictionarydialog.ui: Define focusable widgets in order
for more background.
The tab page can be triggered like this:
* start Writer
* "Tools" -> "Options"
* "Internet" -> "Proxy"
Change-Id: I7f0bbe084dc75a61a0cbedf8184f4ee7aa374e4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207768
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Don't use two separate columns, but put the pixbuf
showing the currently selected color and the text
into the same column. This avoids extra space
between the color in the first column and the
text in the second column seen when using qt6
with native widgets enabled in a WIP branch
where support for the "Tools" -> "Options" dialog
is enabled.
The tab page can be triggered like this:
* start Writer
* "Tools" -> "Options"
* "Charts" -> "Default Colors"
For gtk3, this depends on previous commit
Change-Id: I5c3a29790f593f07c04f23deb8bc993a893a00db
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 8 11:34:57 2026 +0200
tdf#130857 gtk weld: Consider expander image col in TreeView::do_insert
because otherwise the pixbuf showing the color would no longer
be visible.
Change-Id: I9727a508cd18ad48814a054432c376b5ca3d6038
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207765
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The name of "cellrenderertext1" initially made me think
this is a GtkCellRendererText, but it is actually a
GtkCellRendererPixbuf. Rename it to avoid confusion.
The tab page using this UI file can be triggered like this:
* start Writer
* "Tools" -> "Options"
* "Charts" -> "Default Colors"
Change-Id: Ifbc79a65e1149360c7e73c0b6b48ead79c16c152
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207762
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch the order in which the widgets in the .ui file
are defined so that the order better matches the visual appearance
and logical order, which makes sure that tab focus order with the
Qt-based VCL plugins is correct as well when using native Qt
widgets (SAL_VCL_QT_USE_WELDED_WIDGETS=1), where
focus order is (by default) based on widget creation order.
See
commit 02692566ad
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Oct 24 17:43:35 2024 +0200
tdf#130857 optnewdictionarydialog.ui: Define focusable widgets in order
for more background.
The tab page can be triggered like this:
* start Writer
* "Tools" -> "Options"
* "LibreOfficeDev" -> "Fonts"
Change-Id: Ib7ae30a47f78f319a113ef3ecd2184daa00c29b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207598
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
To solve the trade-off between better spacing and less hyphenation,
support hyphenation level and its user interface, the hyphenation
slider, like DTP software do.
Add new paragraph property com::sun::star::text::ParaHyphenationLevel
The hyphenation slider is the basic interface of DTP software to adjust
single (or all) paragraphs using better word spacing (i.e. more
hyphenation) or less hyphenation (i.e. worse word spacing). It allows 1)
to choose the best from the near equally good layouts and 2) to solve an
extreme bad layout (caused by words without hyphenation or other corner
cases).
– 50% hyphenation level means disabled hyphenation, if minimum
and maximum word spacing settings allow to break the line within
words (default interoperability value).
– 100% hyphenation level means using extra hyphenation only if that
results better word spacing in the line, than breaking within words.
– Between 50% and 100% hyphenation level, use extra hyphenation only if
its weighted word spacing is better, than breaking the line between
words (weighting grows with the hyphenation level).
– Between 0% and 50% hyphenation level it means disabled hyphenation
with increased desired and maximum word spacing, depending on the
hyphenation level. At %0, the desired word spacing is enlarged to the
original maximum word spacing, while maximum word spacing is enlarged
by a single space.
For example, the original 4-page unit test document with the default 50%
hyphenation level contains 14 hyphenations. 100% hyphenation level
results in 22 hyphenations, while 0% only results in 8 hyphenations.
– sw/qa/extras/layout/data/tdf167648_minimum.fodt,
sw/qa/extras/layout/data/tdf169168_minimum.fodt: set maximum
word-spacing to 100% from 101% to limit the original unit test only
for minimum letter spacing.
More information: LO/COOL Book & Typography projects:
https://www.numbertext.org/typography/https://www.numbertext.org/book/
Follow-up to commit cf104be5cb "tdf#119908
tdf#166113 cool#15973 sw smart justify: fix DOCX hyphenation",
commit d572576dd6
"tdf#119908 cool#15973 sw smart justify: fix "smart" hyphenation",
commit 529755f091
"tdf#166113 sw smart justify: adjust algorithm for interoperability" and
commit 7d08767b89 "tdf#130088 tdf#119908
smart justify: fix DOCX line count + compat opt."
Change-Id: I84b3893ea6c5cd4eff74a73514722285e7071392
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207545
Reviewed-by: László Németh <nemeth@numbertext.org>
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>
This fixes a 4.2 regression from
324141f21b
where Hide = TRUE ;
was set to <property name="visible">True</property>
In Impress and Draw, although they do have paragraph styles,
they do not support an Automatic first line indent.
So don't show that option when the tab is loaded in Draw/Impress.
The same is true for contextual spacing's
'Do not add space between paragraphs of the same style'.
Prior to 4.2, for Writer it seems to be an implementation error
that contextual spacing was not enabled on paragraph styles,
only on direct paragraph properties.
So I enabled it now - as per SvxStdParagraphTabPage::PageCreated.
Change-Id: If68a511e515b928d04d14ef231ecb01cfc8377ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207480
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
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>
Probably introduced to avoid nonsense values like km all settings
was rejected and mm used. We should allow users to full configuration
and km was removed from the list anyway.
Change-Id: I4e71218334f2ba7cb52b5663c12c7314b6c7a063
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207354
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
Switch the order in which the widgets in the .ui file
are defined so that the order better matches the visual appearance
and logical order, which makes sure that tab focus order with the
Qt-based VCL plugins is correct as well when using native Qt
widgets (SAL_VCL_QT_USE_WELDED_WIDGETS=1), where
focus order is (by default) based on widget creation order.
See
commit 02692566ad
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Oct 24 17:43:35 2024 +0200
tdf#130857 optnewdictionarydialog.ui: Define focusable widgets in order
for more background.
The tab page can be triggered like this:
* start Writer
* "Tools" -> "AutoCorrect" -> "AutoCorrect Options..."
* switch to the "Localized Options" tab
Change-Id: I577cf7d00360c0951669775d4749e0b94b345845
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207312
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch the order in which the widgets in the .ui file
are defined so that the order better matches the visual appearance
and logical order, which makes sure that tab focus order with the
Qt-based VCL plugins is correct as well when using native Qt
widgets (SAL_VCL_QT_USE_WELDED_WIDGETS=1), where
focus order is (by default) based on widget creation order.
See
commit 02692566ad
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Oct 24 17:43:35 2024 +0200
tdf#130857 optnewdictionarydialog.ui: Define focusable widgets in order
for more background.
The tab page can be triggered like this:
* start Writer
* "Tools" -> "AutoCorrect" -> "AutoCorrect Options..."
* switch to the "Replace" tab
Change-Id: I3372ab86e710b72936c88f5e120bc82215a0f36d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207311
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Only a single checkbox is actually used in the first
column ("[L]") in this dialog, so drop the other one
and corresponding model columns.
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.
The use of multiple same renderers in the first column
was identified by ui-rules-enforcer with upcoming commit
Change-Id: I637e50477ce41a7ceca8f9cf5830e383b5393c69
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jun 25 11:15:58 2026 +0200
tdf#130857 ui-rules-enforcer: Check column doesn't have multiple same renderers
in place.
The tab page can be triggered like this:
* start Writer
* "Tools" -> "Options"
* "Load/Save" -> "Microsoft Office"
Change-Id: I4d7ce5b0472e3a22c441b49dcd54ba2b068702e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207308
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The tab page can be triggered like this:
* start Writer
* "Tools" -> "AutoCorrect" -> "AutoCorrect Options..."
* switch to the "Word Completion" tab
Change-Id: I03c639e19805639b8165017466e0fdae492f71ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207306
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The tab page can be triggered like this:
* start Writer
* "Tools" -> "AutoCorrect" -> "AutoCorrect Options..."
* switch to the "Exceptions" tab
Change-Id: Iea7ae02c36f398f75d684391d9420bb93ad49889
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207305
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Only a single checkbox is actually used in the first
column ("[M]") in this dialog, so drop the other one
and corresponding model columns.
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.
The use of multiple same renderers in the first column
was identified by ui-rules-enforcer with upcoming commit
Change-Id: I637e50477ce41a7ceca8f9cf5830e383b5393c69
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jun 25 11:15:58 2026 +0200
tdf#130857 ui-rules-enforcer: Check column doesn't have multiple same renderers
in place.
The tab page can be triggered like this:
* start Writer
* "Tools" -> "AutoCorrect" -> "AutoCorrect Options..."
* switch to the "Localized Options" tab
Change-Id: I730f5c0da3b59827b629d6cbce435340ae04da66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207304
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Only a single checkbox is actually used in the first
column ("[L]") in this dialog, so drop the other one
and corresponding model columns.
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.
The use of multiple same renderers in the first column
was identified by ui-rules-enforcer with upcoming commit
Change-Id: I637e50477ce41a7ceca8f9cf5830e383b5393c69
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jun 25 11:15:58 2026 +0200
tdf#130857 ui-rules-enforcer: Check column doesn't have multiple same renderers
in place.
The tab page can be triggered like this:
* start Writer
* "Tools" -> "AutoCorrect" -> "AutoCorrect Options..."
* switch to the "Options" tab
Change-Id: I6db75571098de91f549404d0b9255b55ee4829d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207302
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The tab page using it can be triggered like this:
* start Writer
* "Tools" -> "AutoCorrect" -> "AutoCorrect Options..."
* switch to the "Options" tab
Change-Id: Id6dc5f4ab634c50293b03ee40db793b44f025f31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207301
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The dialog can be triggered like this:
* start Writer
* "Tools" -> "AutoCorrect" -> "AutoCorrect Options..."
* switch to the "Options" tab
* click on the "Combine single line paragraphs if line
length greater than 50%" entry in the treeview
* click the "Edit..." button
Change-Id: I9474244cb35fe9bd967bd42dba5018690e407065
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207299
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The Character dialog registered a change only when the family name
differed, so picking an extended style of the same family (say a width
such as "Condensed") updated weight/italic but never stored the chosen
subfamily.
Store the chosen style as the text's typographic subfamily, and detect
style-name-only changes too. R/I/B/BI styles stay weight/italic-only, so
common case is unaffected. Since the style box is localized, we map it
back to the font’s own style name to keep the stored subfamily
locale-independent, and show it again on reset.
Change-Id: I9cef7071af1c62829572253f7c9f6cee36ad8266
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207330
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
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>
The Macro Manager dialog now keeps track of which XModel every node in
the tree is coming from just like the Run Macro and Organize Macros
dialogs. That way it can determine whether a macro should be runnable
based on whether it’s in a document rather than whether the user happens
to be looking at a document that has macros. This also fixes a problem
where the run button would not work from the start center.
The UI test is heavily copied from the UI test for the run macro dialog.
Change-Id: I8a47234511fa78ba7d2f97f78f42df8f58416cbc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207244
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
With previous commit
Change-Id: I1ab202cc0d3b5a6ff5d220f4b8e90c578f591158
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 19 22:21:48 2026 +0200
tdf#172513 ko char conv: Preserve char represented by >1 UTF-16 code unit
in place, the issue of invalid UTF-16 strings being used
is fixed now, so set a11y names for the icons in the IconView.
Without that fix for tdf#172513 in place,
passing invalid UTF-16 strings to
GtkInstanceIconView::set_accessible_name
would have resulted in asserts when trying to convert them
to UTF-8 strings as mentioned in the commit message of
Change-Id: Id2e3fea69b3effdd162ad9e0907d38543e415d5e
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 19 16:34:48 2026 +0200
tdf#130857 cui: Port HangulHanjaConversionDialog from ValueSet to IconView
that introduced the use of the weld::IconView:
> No accessible name is set for the icons yet, to avoid
> triggering an assertion when using the gtk3 vcl
> plugin. This is blocked by preexisting bug tdf#172513
> ("Korean Hangul/Hanja conversion may suggest/result in
> invalid Unicode characters") because the use of invalid
> UTF-16 strings would result in those asserts being triggered.
>
> Pending/suggested solution for that one:
> https://gerrit.libreoffice.org/c/core/+/207017
>
> Setting the accessible name will be implemented in a separate
> commit on top of that change.
> However, the switch to IconView without setting an accessible
> name cannot be considered a regression either, as non was
> set for the previous implementation based on ValueSet either,
> so only names like "Item 1", "Item 2" etc. would be used that
> don't give much of a clue what characters what character was
> actually selected.
The dialog can be triggered like this:
* start Writer
* paste text "한글맞춤법" into the document
* select the text and set the language to "Korean (RoK")
* "Tools" -> "Language" -> "Hangul/Hanja Conversion..."
Change-Id: Ica181fa2ddac4e3307b8c6491fdeb94ede8dfd3b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207097
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Justin Luth