Move QueryDialog from cui to a public svtools header.
This is in preparation of using the class directly
and dropping the AbstractQueryDialog abstraction
altogether.
The dialog can e.g. be triggered like this:
* start Writer
* Ctrl+Shift+S for "Save As"
* select "Text (.txt)" for the file type
* press OK
(Resetting the profile ensures the dialog gets shown
in case the "Don't show again" checkbox has been ticked
previously.)
Change-Id: I57bdade32c21c7ab40c5a4c90bd86e8dea5d2fad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210136
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
* 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>
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
* 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>
As mentioned in earlier commit
commit 7c42839f7b
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Feb 17 15:43:22 2026 +0100
tdf#158280 Move SvxNameDialog etc. from cui to svtools
, SvxNameDialog can now be used directly instead
of via the AbstractSvxNameDialog abstraction.
Now that all users of AbstractSvxNameDialog have been ported
to use SvxNameDialog directly in previous commits, drop
the now unused AbstractSvxNameDialog altogether.
Change-Id: Iff696fa557ba0bf80a5f2976271ce83bda1e5aec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199747
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
tdf#158280 suggests to replace all uses of
the sfx2 InputDialog with SvxNameDialog.
For uses in sfx2 itself however
(e.g. sfx2/source/doc/templatedlg.cxx, see work-in-progress
change [1]), this poses the problem that even the existing
AbstractSvxNameDialog abstraction is not sufficient
to avoid a cyclic dependency because the
SvxAbstractDialogFactory required to create
an instance is in the svx module, which is
still above the sfx2 module in the dependency chain.
Move SvxNameDialog and the other common dialogs
defined in the same header down into svtools and
make the header a global svtools header,
so it can be used directly in sfx2 and
elsewhere.
Existing uses of AbstractSvxNameDialog can be
simplified to directly use SvxNameDialog in
separate commits.
[1] https://gerrit.libreoffice.org/c/core/+/198880
Change-Id: I26023712b09bcd7c303053e88cce40a3e1cae964
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199550
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
... and simplify a bit to no longer use the dialog
factory logic which was needed previously to break
a dependency cycle because the cui module is above vcl.
Further simplification will follow in upcoming commits.
Change-Id: Ie3b0d1090300e249e40e1479a40d01caabbdf573
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195094
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
SpellDialog can't do all of its initialization in the
ctor because it needs to call virtual methods on the
SpellDialogChildWindow* that gets passed as a param,
but that one calls the SpellDialog from its ctor, i.e.
it hasn't been fully initialized yet.
For that reason, the part of the initialization done in
InitHdl was delayed by using a user event (posted via
Application::PostUserEvent).
This also includes setting the dialog title based on
the selected text language.
As a consequence of this, the title, and therefore the
accessible name of the dialog would change after it was
shown, which would result in Orca speech output for the
dialog getting interrupted (see tdf#163802).
Avoid the problem by not depending on the next user
event getting processed, but calling the method
that does the rest of the initialization manually
after the SpellDialogChildWindow constructor has
finished.
In order to do that, add a virtual SfxChildWindow::Initialize
(that does nothing) and override it in the
SpellDialogChildWindow subclass.
Since SpellDialog::Initialize (renamed from SpellDialog::InitHdl)
is now guaranteed to be called before the dialog shows
and that one always sets a title (by calling
UpdateBoxes_Impl), drop the no longer needed
// fdo#68794 set initial title for cases where no text has been processed
// yet to show its language attributes
OUString sTitle = rParent.HasGrammarChecking() ? m_sTitleSpellingGrammar : m_sTitleSpelling;
m_xDialog->set_title(m_xDialog->strip_mnemonic(sTitle.replaceFirst("$LANGUAGE ($LOCATION)", "")));
from the ctor.
Additional fix for GTK 3 to avoid incorrect
object:property-change:accessible-name events from
getting sent when the title didn't actually change [1]:
commit 0cc9e603f4635c31d2a8a5f602869474d329e728
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Aug 4 15:31:06 2025 +0200
a11y: Only notify when window title changed
In gtk_window_set_title_internal, return early
when called with the same title as is already set.
This also ensures that notifying of a change
of PROP_TITLE only happens when the property
actually changed, which also prevents invalid
object:property-change:accessible-name AT-SPI
events from getting emitted on the accessibility
layer when the title hasn't actually changed.
Fixes: #7690
Part-of: <https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/8814>
Output of the pyatspi listener script from tdf#163802,
attachment 197494 for gtk3 before this LO commit (note the
object:property-change:accessible-name event after
the object:state-changed:showing event):
event type: object:property-change:accessible-name, event source: Spelling: , states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE']
object:property-change:accessible-name(0, 0, Spelling: )
source: [dialog | Spelling: ]
host_application: [application | soffice]
sender: [application | soffice]
event type: object:state-changed:showing, event source: Spelling: , states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE']
object:state-changed:showing(1, 0, 0)
source: [dialog | Spelling: ]
host_application: [application | soffice]
sender: [application | soffice]
event type: object:property-change:accessible-name, event source: Spelling: English (UK), states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE']
object:property-change:accessible-name(0, 0, Spelling: English (UK))
source: [dialog | Spelling: English (UK)]
host_application: [application | soffice]
sender: [application | soffice]
Output with this change in place:
event type: object:property-change:accessible-name, event source: Spelling: English (UK), states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE']
object:property-change:accessible-name(0, 0, Spelling: English (UK))
source: [dialog | Spelling: English (UK)]
host_application: [application | soffice]
sender: [application | soffice]
event type: object:state-changed:showing, event source: Spelling: English (UK), states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE']
object:state-changed:showing(1, 0, 0)
source: [dialog | Spelling: English (UK)]
host_application: [application | soffice]
sender: [application | soffice]
[1] https://gitlab.gnome.org/GNOME/gtk/-/commit/0cc9e603f4635c31d2a8a5f602869474d329e728
Change-Id: I6cdfe8443ae435e1e644b78942cf63e9df1d400f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Toolkits like GTK and Qt, as well as other platforms
provide a native color chooser dialog
(like GtkColorChooserDialog [1] or QColorDialog [2]).
So far, these have not been used by LibreOffice, but
the custom LibreOffice color picker
(logic implemented in cui class ColorPickerDialog,
wrapped by vcl class ColorDialog and created via
a dialog factory to avoid dependency cycles) has
always been used.
In order to prepare for supporting native color choosers,
introduce a new weld class/interface weld::ColorChooserDialog
(following the convention to name after the GTK equivalent,
GtkColorChooserDialog).
Adjust the existing vcl ColorDialog class to wrap
the new weld::ColorChooserDialog instead of wrapping
the custom LO implementation directly.
Similar to SalInstance::CreateMessageDialog, add a
new SalInstance::CreateColorChooserDialog to create
an instance of weld::ColorChooserDialog. This will
allow to return a toolkit/platform specific implementation
in the future.
Initially, let both SalInstance and GtkInstance
return a weld::ColorChooserDialog implementation
that wraps the existing ColorPickerDialog.
(GTK needs a separate implementation because
the VCL implementation expects that the weld::Window
parent is a SalInstanceWindow, while it is a
GtkInstanceWindow for the GTK case.)
No change in user-observed behavior is intended yet
by introducing this extra layer of weld abstraction,
but this prepares for switching the GTK
implementation to use a native GtkColorChooserDialog
in an upcoming commit.
[1] https://docs.gtk.org/gtk3/class.ColorChooserDialog.html
[2] https://doc.qt.io/qt-6/qcolordialog.html
Change-Id: I29380607cdf3abe739a245aeb25526f643dfa537
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188342
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
it started to crash after
commit ca6b1677cc
Author: Xisco Fauli <xiscofauli@libreoffice.org>
Date: Tue Jun 3 11:59:57 2025 +0200
sw: no need to create a dummy attr pool
because that target pool is nullptr in SfxItemPool::GetUserOrPoolDefaultItem
now.
After some testing, there are some reasons why I believe it should be
dropped:
* Although it's an Writer/Web option it only works on Web ( File - New -
HTML document )
* Even if set in a web document, it won't be exported to html. To do so,
it has to be set in the Page Style dialog
* The document background can be changed from the Apperance tab so
basically this tab is duplicated now
This issue would have be caught if tdf#49895 had a test.
I will write a UItest in a follow-up commit
Change-Id: I3087a6942b9e5406de936fdde47d4c9143be55e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187754
Tested-by: Jenkins
Reviewed-by: Sahil Gautam <sahil.gautam@collabora.com>
Now that the UNO abstraction and corresponding services
have been dropped in
commit 0905c23676
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 13 18:27:09 2025 +0200
Stop using UNO abstraction for color picker
and
Change-Id: I9264707df57e46192a393f6736257c413e5d9831
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Jun 16 08:01:55 2025 +0200
[API CHANGE] Drop ColorPicker, AsynchronousColorPicker
, no longer pass a sal_Int16 param to the ColorPickerDialog
ctor, but use the vcl::ColorPickerMode enum directly
without casting.
This also means that there is no more need for the
underlying int values of the enum values to have a
specific value, so no longer set these explicitly.
Change-Id: Ife2a7b0672bacc73b3001ef0e2e57f4626837655
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186539
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
SvColorDialog is using an instance of
ColorPickerDialog under the hood.
So far, the ColorPickerDialog instance was
created and used via UNO abstraction, by
calling either
css::cui::ColorPicker::createWithParent (for the
synchronous case) or
css::cui::AsynchronousColorPicker::createWithParent
(for the async case), which would end up calling
the UNO service ctor,
com_sun_star_cui_ColorPicker_get_implementation
(and creating an instance of ColorPickerDialog
in both cases, just with a reference to a different
UNO interface as a return value for both cases).
Further interaction would then happen via the
XExecutableDialog or XAsynchronousExecutableDialog
UNO interfaces and by setting/reading properties.
Stop using that UNO abstraction and instead
introduce AbstractColorPickerDialog as a new
VclAbstractDialog subclass, which allows to
interact with the the ColorPickerDialog more
directly while still avoiding a direct dependency
on (the higher-level module) cui in svtools.
This also implies that SvColorDialog now no longer
depends on svt::DialogClosedListener for the async
case, which means that SvColorDialog can be moved
from svtools to vcl in the future. That in turn will
help in implementing support for platform/toolkit-native
alternatives for the color picker instead of using
the LO-internal one.
No change in user-observable behavior intended
or seen in a quick test in Writer (open dropdown for
"Font Color" toolbar item, then select "Custom Color"
to open the dialog).
Change-Id: I3b9997b73a9a6bcce4c5b3ae3bd7d57816a4419b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186468
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The scope of this dialog has changed with 98d1ac254bd62dff9d0aa9c72ba879d1d52495ef
and it's not just an UI for the ToolbarMode namespace
* Toolbarmodedlg* renamed to UIPIckerdlg*
* UNO command ToolbarModeUI renamed to UIPicker
* SID_TOOLBAR_MODE_UI renamed to SID_UI_PICKER
Change-Id: Id4d617aeee83ae1800d4b9a2d207d28c391dcdb4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185789
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
* some nicer strings, depending on whether run as first-start
dialog or after an update
* checkbox to not show the dialog again (but the infobar)
Change-Id: I6b1fafbf70e06a80a4e92864acce5cd16b85bc8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185552
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
With tabs for introduction (and later perhaps also as what's new
info), appearance, and UI picker.
Run ./soffice --safe-mode to test but make sure to start the app
next in normal mode
Change-Id: Ia12ba44c8796fb53f2ec1dbaf46dd25a6ec113cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184195
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Add a ctor to /opt/lo/bin/clang-format -i include/vcl/abstdlgimpl.hxx
to construct the dialog in-place, to simplify factory methods.
And move two abstract dialog impls where all others are in cui
Change-Id: Ia3f3a5d6c1aaa5a9aca9c11990f833842e4536e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178983
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
(make from 5 existing only one)
Much of what makes up this patch is adapted from existing code that is
used to organize and select macros and to assign macros to shortcut
keys. Comments in the patch say where code is borrowed from.
Known issues:
+ Scripting framework library rename for BeanShell, Java, and JavaScript
always returns fail when there are no macro entries in the library even
though it actually succeeds. The same thing happens using
SvxScriptOrgDialog::renameEntry.
+ Deleting Basic macros from the Macro Manager dialog is not implemented
yet.
Change-Id: If4da04549f8b39675910cbbd1f94dd9a6b73c31a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176254
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
To test the new dialog, change org.openoffice.Setup > Product > ooSetupLastVersion to some lesser value for the WhatsNew dialog or clear the entry for the Welcome version.
Change-Id: Iec6de50edba0e5430e82f1db85e61d1e4501771d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163739
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
which means I can remove one usage of gb_Library_set_plugin_for, which
is blocking linking the cui module into --enable-mergelibs=more
Change-Id: Ic6cd48377627f94747037c7247a1cd398738b390
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163820
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
remove CUI_DLLPUBLIC from stuff which is not exported
then drop the cui/include dir which is then empty and
the places we link to cui where we now don't need to
and restore cui back to a lib containing stuff that
doesn't need to be explictly linked to in keeping
with original #i106421# idea
Change-Id: I21894e6f8529dd3306df345fb52dbf5009015f3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162798
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Open Security Option Setting page directly from Security pop up
warning infobar.
Follow up of 1f440348eb
(tdf#157482 UI: Turn Security Warnings popup windows into infobars)
Change-Id: Iac116677801bdb13a9680bcfdf532ec3d874ce0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162393
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Andrea Gelmini