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: I5b23b02151c75bb49831a2bbf8d515eb0b54415e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199068
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>
As described in previous commit
Change-Id: I8e41fb68d5b5e4c3e892803e4139c30f14019f3c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Sep 17 11:23:53 2025 +0200
tdf#104833 update check: Start using vcl::Window more directly
, the update check dialog doesn't use the standard
approach of a .ui file where mnemonic widgets can
be set at this point in time.
With the above commit in place, the mnemonic widget
can however be set in code now, using FixedText::set_mnemonic_widget.
Do that for now so that the accessible relations get
set correctly. (Eventually, the dialog should still
get welded, i.e. converted to use the standard
approach, but don't block making it more accessible
on that.)
This makes the Orca screen reader with the qt6
VCL plugin on Linux now announce the associated
label when one of the readonly text views receives
focus, e.g. it now says
"Status, LibreOfficeDev 26.2 is up to date." instead of
just "LibreOfficeDev 26.2 is up to date." when that control
receives focus, so the context is now clear.
Change-Id: Ic9ad5e7042ff76c493394b2b119c6df80b0abdaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191075
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Define VCL_INTERNALS in order to be able to use the ProgressBar
widget directly until this dialog eventually gets ported to
use the standard weld approach.
This replaces the last uses of UpdateHandler::setControlProperty.
See previous commit
Change-Id: I8e41fb68d5b5e4c3e892803e4139c30f14019f3c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Sep 17 11:23:53 2025 +0200
tdf#104833 update check: Start using vcl::Window more directly
for more background.
Change-Id: I9b8f479eb878b3454863c021ab9732048247df10
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191074
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
UpdateHandler implements a dialog that is created
and was so far updated using UNO API.
Start using the underlying vcl::Window objects
and methods more directly.
Start with the 3 edit controls.
This reduces the use of UNO API and having access to the
underlying vcl::Window objects will also allow setting
the mnemonic widgets (and therefore accessible relations)
for labels in an upcoming commit, for which no UNO
API exists.
Ideally, this dialog should be converted to use
the standard approach of defining its widgets
in a .ui file and then using the weld::Widget
abstraction. Switching to that approach should also be
easier with this commit in place.
Change-Id: I8e41fb68d5b5e4c3e892803e4139c30f14019f3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191073
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... instead of a hard-coded 2 and a comment explaining
that this is the value of RET_YES.
Change-Id: I7caabe2583cea3e36c75777a925b7b1f96dc7281
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191065
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The problem is that curl 8.3.0 removed the NSS backend, so we now
have no other choice than to use the bundled OpenSSL on Linux.
Currently any curl https connection fails with:
CurlSession.cxx:963: curl_easy_perform failed: (60) SSL certificate problem: unable to get local issuer certificate
Apparently this requires manually telling curl which CA certificates to
trust; there is a configure flag --with-ca-bundle but that is useless as
it tries to load the file relative to whatever is the current working
directory, and also did i mention that there are at least 3 different
locations where a Linux system may store its system trusted CA
certificates because ALL ABOUT CHOICE.
So add a new header with an init function to try out various file
locations listed in this nice blog article and call it from way too many
places that independently use curl.
https://www.happyassassin.net/posts/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/
TODO: perhaps bundle a cacert.pem as a fallback in case the system chose
to innovate by putting its certificates in yet another unexpected place
(regression from commit c2930ebff8)
Change-Id: Ibf1cc0069bc2ae011ecead9a4c2b455e94b01241
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158915
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
"CURLOPT_REDIR_PROTOCOLS_STR" has been added with Curl 7.85
so check if Curl version is 7.85 min or use the previous version "CURLOPT_REDIR_PROTOCOLS"
Change-Id: Iacf6a3c37aba63d615eaa93352b098b1c9183533
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145208
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
I am guessing that state in this object is being touched from
multiple threads (since it is an UNO service object), and one or
more of the threads are consequently seeing inconsistent state.
Change-Id: Ib925740d3b8db2713c4f132d0367b794a412a269
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144248
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
and not just the active one, so they are of a consistent height with
eachother. BubbleWindow is only shown for the active one.
Change-Id: I157c8c8b0e2a219c20ffde01ec4a04ba93b7f0e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143241
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Michael Weghorn