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
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>
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>
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>
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
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.
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 ScreenShotEntry class and ScreenShotCollection
typedef out of weld.hxx into an 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: I3a040759e2ae6cd056613c598062e9716ee04649
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205888
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: 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: I2eb564b2483b052f01d4af55fd4feb00b5ed6031
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205472
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
* Checkbox label and position as well as button width and margins
at the UI changed
* Consistent access to the variable via a new class including
the consistent storage of the query flag
* Additional buttons added to have homogeneous Yes/No as well as
non-homogeneous long names, eg. for file formats
Change-Id: Icfbd923b298e1192a1474519543986142167f6c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203572
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
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>
In MacroManagerDialog::SelectHdl remember the TreeView widget
for the m_xScriptContainersListBox and use that instead of the
TreeView param after checking that both are the same widget.
This prepares for switching the signal/handler param to
weld::ItemView& in an upcoming commit, in order to deduplicate
the weld::TreeView and weld::IconView implementations by moving
the logic to their shared weld::ItemView base class.
Change-Id: I751e7b4018de6fcb321819375e92f83bd4da4122
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203354
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use SvxThesaurusDialog::m_xAlternativesCT directly instead of
the weld::TreeView& param passed to the handler.
That is the weld::TreeView that the handler is connected to.
This prepares for switching the signal/handler param to
weld::ItemView& in an upcoming commit, in order to deduplicate
the weld::TreeView and weld::IconView implementations by moving
the logic to their shared weld::ItemView base class.
Change-Id: I4ab385d1db78490d6215d98e958ffca08da0c38f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203353
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use SvBaseLinksDlg::m_xTbLinks directly instead of
the weld::TreeView& param passed to the handler.
That is the weld::TreeView that the handler is connected to.
This prepares for switching the signal/handler param to
weld::ItemView& in an upcoming commit, in order to deduplicate
the weld::TreeView and weld::IconView implementations by moving
the logic to their shared weld::ItemView base class.
Change-Id: I0d0488cb49ae5451e2f6612c50618dad7fb30547
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203352
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
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>
Use SvxThesaurusDialog::m_xAlternativesCT directly instead of
the weld::TreeView& param passed to the handler.
That is the weld::TreeView that the handler is connected to.
This also prepares for adjusting weld::TreeView::m_aRowActivatedHdl
to pass the weld::TreeIter of the activated entry instead of just
the TreeView itself.
Change-Id: I5bb8657367c7516e210b003bf385286cf16351a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203293
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
A later patch will make the Python script provider add an example macro
whenever a new script is created. If we don’t set bChildrenOnDemand to
true then the tree view entry won’t be expandable and the user won’t be
able to find the new macro.
Change-Id: I93327388719556958635b10464cf35d4878b21ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202850
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Otherwise when the create button is used to insert a new macro, the new
item is immediately selected but the buttons remain in the state of the
container. This was confusing because it looked like you couldn’t edit
the new macro.
Change-Id: Ibabe205a1724ed6b64bd45a4cac4d60d2cfad616
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202854
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
This assert was introduced in
commit 2e0381693b
Date: Fri Jul 4 08:11:19 2025 +0000
Fix out-of-bound crash in test dialog 2
, but triggers for gtk3:
soffice.bin: .../cui/source/dialogs/widgettestdlg.cxx:82: void WidgetTestDialog::FillTreeView(): Assertion `nWidth > 0 && "suspicious to get a value like this"' failed.
Remove it for now to make the dialog work again with gtk3.
Possibly the method only returns a useful value after layout
has happened for gtk3 - see also this commint in
GtkInstanceTreeView::get_column_width:
virtual int get_column_width(int nColumn) const override
{
GtkTreeViewColumn* pColumn = GTK_TREE_VIEW_COLUMN(g_list_nth_data(m_pColumns, nColumn));
assert(pColumn && "wrong count");
int nWidth = gtk_tree_view_column_get_width(pColumn);
// https://github.com/exaile/exaile/issues/580
// after setting fixed_width on a column and requesting width before
// gtk has a chance to do its layout of the column means that the width
// request hasn't come into effect
if (!nWidth)
nWidth = gtk_tree_view_column_get_fixed_width(pColumn);
return nWidth;
}
To trigger the dialog:
* in "Tools" -> "Customize", set a keyboard shortcut for
function/UNO command ".uno:WidgetTestDialog"
* close the dialog and activat the shortcut
Change-Id: I0e2c25636acad995bdd0b5c225c48079a13fcc89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201938
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Moved creation of Undo/Redo actions for geometry changes directly
to the methods addDiagramNode/removeDiagramNode of class
DiagramHelper so that not every caller has to do that again.
Removed from DiagramDialog where that was done before.
Extended DiagramDataState which is used for SdrUndoDiagramModelData
with needed Model information. After using SdrModel/XShape data
as part of the DiagramModel it is necessary to also keep that
info when geometry gets changed. Also the current transformation
of the group hosting the Diagram is needed. Also the end state
of change in SdrUndoDiagramModelData is now late-evaluated
to get the changed state. This is needed in redo, so evaluating
this if undo is used is the thing to do.
Added a general mechanism to apply locks to the SdrObjects,
see applyLocksToDiagramObjects. It currently sets MoveProtect,
ResizeProtect and DeleteProtect. These get un-set when the
Diagram is reverted to a simple SdrObjGroup to not hinder
further editing.
There is currently no ToFront/ToBack lock or others which
may be needed. In principle all geometric changes to objects
of the Diagram need to be blocked.
Also still missing is that the BackgroundObject has no
LineAttributes, or better is not allowed to have these due
to mso only offering a FillStyle for that object. Not sure
yet how to do that.
Added a mechanism to automatically delete the buffered
original data when attributes change, see
ItemSetInformationChange. This is triggered by
AttributeProperties::ItemSetChanged, but needs to be
prevented during import (which also changes Items).
Added support to delete the SubSelected object if it
is a TextFrame. This leads to geometry change and
re-layout and also creates a Undo action now.
Attribute access to SubSelection is done in
SdrEditView::MergeAttrFromMarked/SetAttrToMarked
so that attributes can now be changed like for
regular objects.
Also some methods in SdrMarkView had to be adapted to
work with the SubSelected object.
Extended Diagram SubSelection to make tab/ShiftTab work, including
from where the Diagram is entered. Also made direct MouseKlick
work.
Added simplifications to work with Diagram stuff, some
tooling directly at SdrObject.
Due to UnitTests I reverted the decision to have all SdrObjects
in the Diagram 'flat' without Groups. That would be easier and
is what the import of MSO visualizationm replacement often uses,
but not what a reLayout creates.
Those complaining tests are the pptx ones that have no replacement
graphics (no drawing*.xml) and have to be re-layouted using our
mechanism as existing so far.
So keep groups again for now. Price is that all stuff handling
SubSelections has to use SdrObjListIter instead of SdrObjList.
That makes it somewhat more complicated, but work on a virtually
flat hierarchy of SubObjects in any case - maybe safer for the
future.
Also looked at that Locking oif SdrObjects again also due to a
test. I wanted to use the extended/newer stuff, but applying it
made the office crash. After some debugging I found that in
SdrObjList::RemoveObject the remove is *cancelled* when
SdrObject::IsDeleteProtect is set for that object. Unfortunately
that remove is due to moving the object to another target
list, so it should happen.
This is probably a relict of very old stuff, to prevent object
delettion that way (!). For now I use the fact that this happens
during import.
Change-Id: Ied2263928106e2cb02047e2e9a55c680384b2932
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201497
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Michael Weghorn