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
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>
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
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
In order to represent the (codepoint of a) Unicode character
in UTF-16, multiple UTF-16 code units may be needed.
So far, the Korean Hangul/Hanja character conversion
was assuming that each Unicode character was only
consisting of a single UTF-16 code unit, and splitting
into single sal_Unicode characters accordingly in
TextConversion_ko::getCharConversions.
This breaks for characters represented by multiple
code units, like "𡽜" (CJK Unified Ideograph [1],
unicode codepoint: 139100/U+21F5C) which is represented
by 2 UTF-16 code units.
As a consequence, an invalid OUString/UTF-16 string would
be passed to HangulHanjaConversionDialog::SetCurrentString
for some of the suggestions.
Fix this by no longer splitting into single sal_Unicode,
but use o3tl::iterateCodePoints to split into actual
code points.
Example: When using "Tools" -> "Language" ->
"Hangul/Hanja Conversion..." for a Korean text of
"한글맞춤법", the string of all characters for potential
conversions in TextConversion_ko::getCharConversions is:
"韓漢寒限閑恨旱汗翰邯罕悍澣閒瀚桿捍閈暵鼾犴僩嫺熯嫻駻鷳扞狠僴覵瞷猂邗骭撊鷴垾憪橌㸁䛞䦘闲鹇娴汉焊闬韩仠佷傼兯哻娨嫨屽晘橺浫澖皔蓒蔊蛝螒豻貋釬銲雗鶾鷼麲㒏㛠㡾㢨㪋㯗㲦㵄䁂䂅䈨䉯䍐䍑䎯䏷䓍䓳䕿䗙䥜䦥䮧𡽜忓"
Previously, the last 3 of them ("䮧𡽜忓") would incorrectly be
split into (stdout output, showing something is wrong):
"䮧", " " (something wrong, but a valid UTF-16 string), "?" (wrong, and invalid UTF-16 string), "忓"
With the fix in place, they remain intact:
"䮧", "𡽜", "忓"
Also adjust HangulHanjaConversionDialog::OnSuggestionModified
accordingly to compare the number of code points the
string consists of, not the number of UTF-16 code units.
Otherwise, the "Replace"/"Always Replace" buttons in the
"Hangul/Hanja Conversion" dialog would remain greyed
out for the above example when selecting the "𡽜" character
(that now correctly gets displayed with the fix in
TextConversion_ko::getCharConversions in place).
Thanks to Jonathan Clark for pointing out that additional
aspect in review!
Add a corresponding test case.
While the fix is in i18npool, the new test is implemented
in editeng, where the HangulHanjaConversion class uses
the i18npool logic via a UNO service.
The test is implemented there because the component context
availabe in i18npool doesn't supply the required service.
The same test implemented there would fail like this:
An uncaught UNO exception
- com.sun.star.uno.DeploymentException: {Message: "component context fails to supply service com.sun.star.linguistic2.ConversionDictionaryList of type com.sun.star.linguistic2.XConversionDictionaryList at /home/michi/development/git/libreoffice/workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/linguistic2/ConversionDictionaryList.hpp:45", Context: @0x7fff17acecf0}
[1] https://codepoints.net/U+21F5C
Change-Id: I1ab202cc0d3b5a6ff5d220f4b8e90c578f591158
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207017
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
The delete button is now enabled when a BASIC macro is selected and it
causes the macro to be deleted using the new shared helper function.
Change-Id: I22ce8787eb753254a94e385d11684e0f0de8a677
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207058
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
Adds GetSelectedBasicModule and GetSelectedBasicMethod to get the
selected SbModule or SbMethod when a node in the BASIC branch of the
tree is selected.
Change-Id: Id97634698b1c838a20026b249720901490de9f52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207057
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
When the run button in the Macro Organizer is pressed for an embedded
script with macros disabled in the security settings it now displays a
dialog box instead of silently doing nothing.
Change-Id: I5bae91570a19e444881d56efc29f3dd735a22a78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207231
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
* Replaced ScOnlyActiveSheetSavedDlg by QueryDialog
* Pimped the QueryDialog with SetTypeWarn showing a different
image and hiding the No button
Change-Id: Id134c8d4f6e27df5918d1b53141b45bc0439651c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207209
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Port SuggestionDisplay used in HangulHanjaConversionDialog
from using the custom SuggestionSet ValueSet subclass to
use weld::IconView instead.
This helps to be more consistent with other platform/toolkit
widgets, reduces custom logic and prepares for enabling
support for that dialog with native Qt widgets
(SAL_VCL_QT_USE_WELDED_WIDGETS=1) in an upcoming commit.
The logic to create the icons now in
SuggestionDisplay::CreateIcon is based on previous
logic to use twice the width of the text "AU"
(as previously set using ValuSet::SetItemWidth
in the SuggestionDisplay ctor; and now twice
height is also used) and the logic to render
the text previously implemented in SuggestionSet::UserDraw.
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: Id2e3fea69b3effdd162ad9e0907d38543e415d5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207096
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>
Since the commit below the notebookbar tab no longer exists on the
customisation dialog. If you open the dialog from the start center the
code tries to remove this tab by name. At least on the GTK backend, this
ends up hitting an assert failure. This patch just removes that code.
commit 7312d7d3c9
Author: Heiko Tietze <tietze.heiko@gmail.com>
Date: Wed May 20 15:28:42 2026 +0200
Relates tdf#166641 - Add category labels to Writer's Tabbed Notebookbar
Change-Id: Id430ef85bba5fb748108b89987bf73ee2acc4257
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206003
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
Now that SfxGroupInfo_Impl stores the model where each script came from
we can expose that information for the selected script in the script
selector dialog via a new method called GetScriptModel.
Change-Id: I7d9baaa99c276842e3b7e6bcacf89a915bcdca33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206151
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
When expanding the root browse node, the FillScriptList function now
finds the XModel for script groups that come from a document. This model
is then stored in the SfxGroupInfo_Impl data for the group. Every time a
group is expanded the model is propagated to the children and finally on
to the FUNCTION_SCRIPT nodes. That way it is possible to determine which
XModel every script comes from, if any.
Change-Id: Ieea6c31b2164a42c07195abf04bd242b28fe1922
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206150
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
Both SvxScriptOrgDialog and CuiConfigGroupListBox had a copy of a
function called getDocumentModel which looks up an XModel given the name
of a document. This patch combines them into one shared utility
function.
Change-Id: I25cafd7658760a1cf02a7bcef9a38e63b02979ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206149
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
Previously SfxGroupInfo contained a void* pointer that worked like a
tagged union to store data depending on the type of the group. The
pointer was cast to the right type depending on the value of the nKind
member. Surprisingly, the SfxGroupInfo has no explicit destructor and
instead the data was destructed in several implementations of ClearAll
to clear the list box. Some of the implementations didn’t handle every
type of group.
This patch makes it store the data in a std::variant instead so that the
default destructor can take care of cleaning up the data properly. nKind
is now moved directly into the index of the variant so that it’s not
stored in two places.
This should make it easier to modify the struct without having to worry
about updating all of the places where the data was destructed.
Change-Id: I3393bb6ab8ea4cfc82c1fd03f345b2f6782785ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206148
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
When building up a tree list from the children of an XBrowseNode the
code was unconditionally taking a reference on each child. I think this
reference is needed in the case when the node has its own children
because it ends up getting stored in an SfxGroupInfo_Impl struct which
has an explicit call to release() when the tree list is cleared. However
if the node doesn’t have children then the reference was apparently
being leaked. If I add some tracing to BrowseNodeAggregator then I can
see that without this patch a bunch of nodes are leaked when the process
closes.
Change-Id: Ie6d2f69101f6eaf2f3a364bc65c286e891615e4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206147
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
Justin Luth