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>
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
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, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ide86f35543468a88288a068cc9f89eaf381ac52f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205763
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I0cc1e0f3aa60d3457af0f0f30ec8fe74cb5ce6a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205489
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I2eb564b2483b052f01d4af55fd4feb00b5ed6031
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205472
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: If7cb4403f1861c465f44a1cae4065b0bf8dfad48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205323
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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>
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>
The package supporting the “pdfium” library has been improved.
Numeric values have been converted to a fixed-size enumeration type.
The changes apply to all occurrences of the older version of this code.
Change-Id: Ie9d0bd98d7c323f890ac3051bb1f08a50d51e046
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201303
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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: I56cea12845bc906a8b7aff13abe033e9723b85c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198614
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
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: I27033905fe8be1c3646c8cf08799c9bf53eeb471
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196448
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: I05a3ae87147fedfa39f4acd8c3f744fd88a83e5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196442
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Converted plain enums to enum class for better type safety:
- xmlreader: Converted two local Space enums to enum class and removed
redundant SPACE_ prefix from enum values (NONE, SPAN, BREAK, START)
- xmlsecurity: Converted EqualMode enum to enum class
- xmlsecurity: Converted local State enum in CompatDNCryptoAPI to enum class
Updated all usages across 8 files to use scoped enum syntax.
Change-Id: I27fd7280bccad72a43cda3b669b1f0926c34271c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196207
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
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: Ifbd413fc8dcfe5e453a0fef8a04f3c396af4c836
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195781
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This is in preparation of moving code out of weld.hxx
to separate headers/source files, in order to make it
easier to keep an overview and to avoid having to
recompile ~all UI code when anything changes.
Also move weldutils.cxx to a new vcl/source/weld
directory.
Change-Id: Ia75b42f21e560dd248307282a522f186a64cd742
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195777
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The path was missing an "s" in "xmlsecurity".
As a consequence, the icon couldn't be loaded, and thus
couldn't be displayed.
For the qt6 VCL plugin with SAL_VCL_QT_USE_WELDED_WIDGETS=1,
it triggered first a warning, and then an assert:
warn:vcl:3089384:3089384:vcl/source/bitmap/BitmapEx.cxx:103: BitmapEx::BitmapEx(): could not load image xmlecurity/res/notcertificate_40x56.png via icon theme breeze
soffice.bin: /home/michi/development/git/libreoffice/include/vcl/qt/QtUtils.hxx:48: QPixmap toQPixmap(const BitmapEx &): Assertion `!aPixmap.isNull() && "Failed to create icon pixmap"' failed.
Support for that dialog was added in previous commit
Change-Id: Ib0ec32ff50744f4e265a743f2b0e5f240253ee5f
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 30 11:51:12 2025 +0200
tdf#130857 qt weld: Support "View Certificate" dialog
The issue could be triggered as follows when a GPG certificate
that is not considered validated is used:
* start Writer
* save doc
* "File" -> "Digital Signatures" -> "Digital Signatures"
* press "Sign Document"
* select an existing certificate/GPG key
* press "View Certificate"
Now, the icon is shown as expected with all of gtk3, gen and qt6.
Path was spelled the wrong way way ever since
commit 7bd87eb30c
Date: Wed Apr 26 09:35:24 2017 +0100
remove xmlsecurity bitmaps from .src files
Change-Id: Icbe2f56dc0b831a0d56fc2707fed6480cb0b9bae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188600
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The final goal of this API is to give time & hash information about the
PDF signature, so once a 3rd-party produces the PKCS#7 signature, that
can be added to the document and the actual PDF sign can be re-run with
the same parameters.
This commit continues the replacement of XCertificate with
svl::crypto::SigningContext up to the point that the timestamp used in
svl/ can be exposed on the LOK API.
This is done by updating DocumentSignatureManager::add(),
PDFSignatureHelper::SetX509Certificate(),
vcl::filter::PDFDocument::Sign() and finally the svl::crypto::Signing
ctor to work with the signing context instead of an XCertificate
directly.
Time reporting works now, so add a test for that. The digest part still
needs doing.
Change-Id: I83f1274cd420b67194b7caf12b1027e623d4f7fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176404
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
1) Move the try-catch around assing a signature inside the block that
already got the response from the certificate chooser, it's unlikely
that choosing the certificate (and not yet signing) would fail.
2) Convert the dialog to async and allow it to be a jsdialog.
3) Hide not relevant widgets for LOK: we have a single signing
certificate, so the search entry is not useful.
The refresh button has an unclear purpose, as it was initially added
in commit fb9874231f (Caching
Certificates in the CertificateChooser dialog session-wise, 2023-08-26),
but later commit efe414c4a8 (Don't reuse
CertificateChooser instances, 2024-02-07) disabled this chaching. In any
case, the certificate won't change during the lifetime of a single LOK
view, so hide that as well.
4) Invoke the inner certificate viewer in an async way, too.
Change-Id: Ibf618ea7632cf801d1d9180b9aa7dd193c45ffda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174215
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Have two views, in case both of them haver sign certs configured in the
NSS database, then the cert chooser would present both, which is not
wanted.
The problem is that the NSS database contains sign certs from all views,
so working from the database is not what we want for the LOK case.
Fix the problem by passing the SfxViewShell from the sign dialog to the
certificate chooser dialog, and then the chooser can work from the view
in LOK mode.
Searching for other uses of getPersonalCertificates(), the comphelper/
one is not relevant for the LOK case (gpg is disabled there); the PDF
case is only for the UNO API, so those don't necessarily need adjusting.
Change-Id: Ic7027b8d218b2bde3c8bf134a4b11c14fd9c3570
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174002
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Open the sign dialog, the Add button is hidden, even if the LOK clients
initializes the view with a working signing certificate.
SfxMedium::SignContents_Impl() knows the correct view, but by the time
the execution arrives to the DigitalSignaturesDialog ctor, this info is
lost, so we don't know what is the current view.
Fix the problem by looking up the view of the object shell at UNO
command dispatch time, and passing that around, so the signature dialog
can also access it. If the view has a signing certificate configured,
then allow signing.
The certificate chooser triggered by this button still needs fixing.
Change-Id: I1fae63cea27ea1e68e938879f4507f53ade484f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173964
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Open an already signed document, click on the sign icon on the status
bar, notice how the button to remove a signature is hidden.
This was added in commit 71a8bad4b9
(jsdialog: enable Digital Signatures dialog, 2022-01-24), which exposed
the signatures dialog as a read-only jsdialog. The dialog was improved
recently to be a read-write jsdialog, so this is no longer needed.
But then DigitalSignaturesDialog::canRemove() had an inner non-async
message dialog. Fix that by converting canRemove() to async.
An additional problem could be that the document is not marked as
modified, so the LOK client code doesn't notice the document is updated
(to not have a signature), but we do update the last mod timestamp of
the file, which is meant to be enough.
Change-Id: I8e7ee22e4b1b8ce59dee3617bb2f22f8d734f31d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173428
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Some functions were already a stub and only aborted on calling them.
The *Package* functions were added in commit
c9ed2f359a (INTEGRATION: CWS xmlsec08
(1.4.24); FILE MERGED 2005/02/22 13:07:19 mt 1.4.24.1: #i36682# Accept
separate Stream for signatures..., 2005-03-10), but it seems nobody
called them.
This also means that DocumentSignatureMode is now never set to
DocumentSignatureMode::Package, so remove that as well.
It seems to be unlikely that this non-published service was used by
3rd-party code, since it was specific to the needs of sfx2/ code, not
generic functionality that could be useful in other contexts.
Change-Id: Icfed9a0e6568f6eb21f9236901af01f1915bf2f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173313
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Sign a document with macros (via file -> digital signatures -> digital
signatures), realize that you still get a warning on file open, sign the
macros in the document (via tools -> macros -> digital signature),
realize that you did this in the wrong order, so now you have to re-sign
the doc content.
The reason for this is that the macro signature only signs the macro
parts of the document (so you can still edit the document and the
signature is valid, as long as you don't touch macros), while the doc
content signature signs everything, including the macro signature, so
the order of the two matters.
Solve this trouble by adding a new setting that allows doing the two
signatures in one step. Do this by extending the doc content signing
code with an optional pre-step that first signs the document macros.
This is a bit tricky to do, since xmlsecurity/ gets an RW signature
stream and a RO document storage from sfx2/, but transferring one more
signature stream can solve this trouble.
Other tricky parts of the change:
1) The crypto signing is always done by libxmlsec, so
DigitalSignaturesDialog::SetScriptingSignatureStream() has to update
the storage of the sign manager's sign helper, otherwise, the hashes in
the macro signature will be empty.
2) Signing reads the RO storage, so normally the macro signature
would not be part of the doc signature when creating both signatures
inside a single dialog. (The storage is only committed after the
dialog ends.) Fix this problem by extending
DocumentSignatureManager::add() and UriBindingHelper::OpenInputStream()
to provide kind of an overlay when xmlsecurity/ gets a script signature
stream: this way the macro signature will be part of the doc signature
while the dialog is in progress. No overlay is needed later, once both
streams are committed to the storage on dialog end.
Change-Id: Ic2728689997165595991d5ec59c7a2683286e22d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173263
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Currently SfxObjectShell::CheckIsReadonly() has a hack for the LOK case
to show the signatures dialog read-only, as only that is async.
The next step is to make DocumentDigitalSignatures::ImplViewSignatures()
async, though that requires all callers of the function to be async, so
make DocumentDigitalSignatures::signScriptingContent() async as well.
There is also DocumentDigitalSignatures::signPackage(), but turns out
that's dead code, so just remove it.
Once this is in place, we had a problem that the callbacks tried to
interact with libxmlsec, but the dialog was still alive in
DocumentDigitalSignatures::ImplViewSignatures() by the time the callback
was running, so there were two DocumentSignatureManager instances at the
same time, and both assumes it should call the global libxmlsec
init/uninit, which resulted in failing to verify the just created
signature.
Fix this similar to how Tomaz fixed the same problem around pdfium in
commit 067a8a954c (pdfium: only init
pdfium library one and destroy on LO exit, 2020-06-03).
Change-Id: I3fb63c06195564732e1576dbd755157e676fb762
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173117
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The NSS password dialog naming the Mozilla profile only shows up for
X.509 certs outside Windows. And the user may wrongly assume GPG keys
are from Thunderbird.
Change-Id: I23706309d57fe30cddcbcac16d7f3e20ee397f16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171645
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
gpgme contexts uses the "auto" trust model by default which only
allows encrypting with keys that have their trust level set to
"Ultimate". The gpg command, however, gives the user the option
to encrypt with a certificate that has a lower trust level so
emulate that bahavior by asking the user if they want to trust
the certificate for just this operation only.
Also, abort saving if no certificates are selected which is an
indication that the user cancelled the Select Certificate dialog.
Change-Id: I20951b1e31b2dcf8adb82243742f8c00fbaca8c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165260
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
The cui module has its own UserData struct and when building with
--enable-mergelibs=more, this data collision will cause a crash
when deleting a UserData instance in the xmlsecurity module because
the cui module already has its own, unrelated UserData struct.
Change-Id: I6418b049c72a2e902c9b5076b72fd240f65a593d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164404
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
using the bin/find-can-be-private-symbols.py script
to find classes with large numbers of exported symbols
that can hidden.
before
exported = 58104
imported = 30810
unused_exports = 35433
after
exported = 55094
imported = 31073
unused_exports = 32423
Change-Id: Idd0a70ee3740afd5ca1a86771e0e2ff8090d102d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163456
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reusing the same instance will, in the following case, lead to a
crash. It appears that the CertificateChooser is getting disposed
somewhere as mpDialogImpl in its base class ends up being null:
1. Create an empty Writer document and add a digital signature
in the Digital Signatures dialog
2. File > Save As the document, check the "Encrypt with GPG key"
checkbox, press Encrypt, and crash in Dialog::ImplStartExecute()
Change-Id: I9aaa1bd449622e018b502d68c53d397255a1b61a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163065
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
This is essentially a footgun because the user can accidentally turn it
off and get non-AdES signatures which use obsolete SHA1 hashes.
Unfortunately it turns out that the initial setting of the checkbox only
works for ODF, because OOXML have m_sODFVersion set to "1.0" due to some
defaulting code somewhere.
So what this checkbox actually did is unintentionally disable XAdES
signatures for OOXML by default.
Now that i actually test it by setting ODF version 1.1 in
Tools->Options, it turns out that signing ODF 1.1 documents isn't
possible at all, a dialog pops up that says "Signing documents
requires ODF 1.2 (OpenOffice.org 3.x)".
Change-Id: I0eaf590c290b2c0ee0ff890ed73f0dbea4cf0ce3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160785
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(*) Make all of it use a "Scoped" paradigm
(*) pass by value, no need to allocate on heap
(*) make all of the construction go via the *Access constructors, instead of it being some via the constructors and some via the Acquire*Access methods.
(*) take the Bitmap& by const& in the constructor, so we can avoid doing const_cast in random places.
Change-Id: Ie03a9145c0965980ee8df9a89b8714a425e18f74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160293
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Seen in a fedora:40 container, using --with-system-libcmis,
--with-system-liblangtag and --with-system-xmlsec.
Change-Id: I9d748d3dc0b70dbfdfcb6b99c9ce8440bda6f326
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159980
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...by moving the char8_t -> char reinterpret_cast out of any potential constexpr
paths into a new TranslateId::getId. And demonstrate constexpr'ability by
making the aCategories var in OApplicationIconControl::Fill
(dbaccess/source/ui/app/AppIconControl.cxx) constexpr. (And there might be more
such cases that could now be made constexpr.)
Change-Id: I0b4e3292faf8f6b901f9b9e934e1aa6bf0f583ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157862
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Michael Weghorn