XWindow2 subclasses XWindow, so there's no need for
a VCLUnoHelper::GetWindow variant taking an XWindow2
reference that does the same as the variant taking
an XWindow reference.
Change-Id: I6f931252d2ae2e046dc31c076094e71b8aa71346
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185273
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
toolkit::IAccessibleFactory and
vcl::IAccessibleFactory are abstract classes
providing methods to retrieve the XAccessible or
XAccessibleContext for different vcl widgets.
Both are implemented by the same class in the
accessibility module: AccessibleFactory
Merge toolkit::IAccessibleFactory into
vcl::IAccessibleFactory to have things in
one place, and have everything in vcl, i.e.
no longer part of it in toolkit that itself
depends on vcl.
Change-Id: I5da571899c9987267cbec2950630d0c44ff4d2f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178643
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Adjust VCLXAccessibleComponent and subclasses to take
a vcl::Window arg instead of a VCLXWindow in the ctor
and drop the VCLXAccessibleComponent::m_xVCLXWindow member
that used to hold a reference to the VCLXWindow.
(VCLXAccessibleComponent still holds a VclPtr
to the corresponding vcl::Window.)
Instead of passing the UNO/toolkit peer (VCLXWindow
and subclasses) to the AccessibleFactory to create
an XAccessibleContext context for the underlying VCL
widget, pass the underlying vcl widget, which can
now be passed as is to the corresponding ctors
of VCLXAccessibleComponent and specialized subclasses.
This follows earlier commits replacing the use of the
VCLXWindow classes by direct uses of the vcl::Window
subclasses inside VCLXAccessibleComponent and subclasses
and is the next step in reducing the UNO/toolkit
dependency in the accessibility implementation for
vcl widgets.
For now, the logic where those accessible objects
are created remains in VCLXWindow::CreateAccessibleContext
and overrides, but that can change in the future.
`IAccessibleFactory::createAccessibleContext(VCLXMultiLineEdit*)`
is just dropped and doesn't need its own replacement:
The previous VCLXMultiLineEdit variant was
creating a VCLXAccessibleEdit like the variant
taking a VCLXEdit, but VCLXMultiLineEdit doesn't
subclass VCLXEdit.
The vcl MultiLineEdit however subclasses Edit,
so VCLXMultiLineEdit::CreateAccessibleContext can make
use of `IAccessibleFactory::createAccessibleContext(Edit*)`
as well now.
This also implements what was mentioned in earlier
commit
Change-Id: I67bb7a6a237e57d0c522790c09a595c02ac06325
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Dec 12 17:16:29 2024 +0100
sw annotation win a11y: Skip VCLXWindow logic
:
> Drop the comment about the code being dodgy from
> SwAnnotationWin::CreateAccessible. This commit partially
> addresses it and switching VCLXAccessibleComponent
> to using the vcl::Window will take care of the rest,
> see upcoming commit
> Change-Id If0894e733273eecad268c6a932ecee7c2e34b4c2
> ("a11y: Stop using VCLXWindow in vcl a11y classes").
Now that the VCLXAccessibleComponent ctor takes a
vcl::Window, the sw::annotation::SwAnnotationWin
can be passed directly.
From a user perspective, no change in behavior is
intended by this commit.
Change-Id: If0894e733273eecad268c6a932ecee7c2e34b4c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178385
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Other than most of the a11y implementations for vcl
classes, VCLXAccessiblePopupMenu etc. do not
make use of any VCLXWindow (i.e. UNO/toolkit wrapper of a
vcl::Window) and thus do not depend on the toolkit
module, which the accessibility module depends on.
Therefore, there's also no need to use the accessible
factory to create them (which is needed when toolkit
classes are involved to avoid a dependency cycle).
Move those classes from the accessibility module to
vcl and add a new method Menu::CreateAccessible and
move the logic from AccessibleFactory::createAccessible
there. Drop the now unnecessary factory methods
previously used for those classes.
No change in behavior intended (yet), but this
also simplifies the code involved for the
tdf#164093 scenario.
Change-Id: Ie3f6f1a02bf6662206d31383473cdc868e1f9164
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177812
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move helpers to convert between the Rectangle, Point and Size
classes in vcl and in css::awt from VCLUnoHelper (in the toolkit module)
to vcl::unohelper (in the vcl module), for reuse in vcl in upcoming
commits.
Change-Id: I7b11c8a6b8c843a01ce25b1e4c0fb1869ad1e6ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177816
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Following
Change-Id: Id48f81deb05aee2026509037f7d14575735e5be0
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 10 14:49:03 2024 +0200
VCLUnoHelper: Align AWT <-> VCL helpers with convert.hxx impl
, port all uses of the helper functions defined in
`include/toolkit/helper/convert.hxx` to use the
`VCLUnoHelper` equivalents instead, to unify usage
and avoid duplication.
Drop `include/toolkit/helper/convert.hxx` now that
it's unused.
Change-Id: I22695a93e40e47bb2b14d191a2e0a4eb7c856895
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170317
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
There are currently (at least) 2 sets of helpers
for converting from AWT to VCL point, rectangle
and size classes - and the other way around:
* the ones in `include/toolkit/helper/convert.hxx`
* the ones provided by `VCLUnoHelper`
Align the `VCLUnoHelper` implementations with the
ones in `include/toolkit/helper/convert.hxx` and
make them inline as well.
Switch params from the specific subclasses to the
more generic base classes as well
(e.g. `css::awt::Point` -> `PointTemplateBase`).
Otherwise, `VCLUnoHelper::ConvertToVCLRect` is the only one
that didn't implement the functionality in the
exact same way as the counterpart, `VCLRectangle`,
as it was manually calculating the right and bottom
edges.
The `VCLRectangle` implementation
gives the same result for valid rects, so take over
that one. (It shouldn't make a difference for the
only 2 current callers, `ControlHolder::getPosSize`
and `VCLXGraphics::clear`.)
This commit is in preparation of consolidating all uses
to use the `VCLUnoHelper` variants and getting
rid of the other one in following commits.
Change-Id: Id48f81deb05aee2026509037f7d14575735e5be0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170316
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
I had done these a while ago, when I looked into extending loplugin:ostr to do
more automatic rewriting, and these were places where I needed to do something
manually, for one reason or another, because the automatic rewriting would not
pick it up correctly.
However, I got distracted, and a wholesale automatic rewrite would still run
into cases where an _ostr/_ustr instance from a library's .rodata would still be
referenced after the library has already been dlcose'd. So I never came around
to finishing all that.
But there appears to be renewed interest in (automatic) rewritings here now, so
it probably makes sense if I share this part of my work anyway.
Change-Id: I3da9d38398e4bca373cb0000a9d34b49a36ad58a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166792
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
Instead of the generic `VCLXAccessibleComponent`,
use `VCLXAccessibleEdit` as a11y class for
`VCLXMultiLineEdit` (the component interface
class for MultiLineEdit) as well, not just for `VCLXEdit`.
With the preparatory changes from
Change-Id I8218db61feb07605f6ea5309f26eebd38312458a
tdf#104833 a11y: Don't use VCLXEdit in VCLXAccessibleEdit
in place, it behaves as expected when interacting
with the multi line edit from the sample dialog in
attachment 189287 in tdf#104833 using Accerciser and
the qt6 or gtk3 VCL plugin (and the text can also be
edited when removing the readonly flag from the control)
or the update dialog (which uses UNO controls,
`UnoControlEditModel` for the panes that were not
announced, s. extensions/source/update/check/updatehdl.cxx ).
In particular, the a11y text interface is supported by
the multi line edit on the a11y layer, which makes
Orca with the gtk3 VCL plugin announce the text content
when the control gets focused.
NVDA on Windows still announces "Checking..." instead
of using the actual text that would be retrievable via
the IAccessibleText interface now. This is probably
because "Checking..." is the (outdated) accessible name,
as can be seen by interacting with the object in NVDA's
Python console:
>>> focus.name
'Checking...'
>>> txt = focus.IAccessibleTextObject
>>> txt.text(0, txt.nCharacters)
'LibreOfficeDev 24.2 is up to date.'
For both, gtk3 and qt6, the a11y object does have the
new text as a11y name as well, as can be verified in
Accerciser:
In [10]: acc.name
Out[10]: 'LibreOfficeDev 24.2 is up to date.'
In [11]: txt = acc.queryText()
In [12]: txt.getTextAtOffset(0,3)
Out[12]: ('LibreOfficeDev 24.2 is up to date.', 0, 34)
Change-Id: Id80e191cdd5342b3215fdb9d2ad3847470366337
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156402
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
to attempt to make it obvious in code what kind of coordinate
system we are dealing with.
The idea is that by doing this, the compile-time type checking
will flush out inconsistencies between different code.
I started with vcl::Window::OutputToAbsoluteScreenPixel
and worked outwards from there.
Change-Id: Ia967d7a0bb38886695f3a761b85c8b9340ddb1c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154676
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Which means creating a variant of the cppuhelper::OPropertySetHelper
helper class which uses a std::mutex.
Since we can do virtual base classes now (which the original could not), use that and a new helper
class comphelper::UnoImplBase to share
std::mutex m_aMutex;
bool m_bDisposing;
fields that the OPropertySetHelper wants to share with the parent class.
Change-Id: I05ad465a3d3653ed4e109137e3e1c58190da8d97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148474
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to try and untangle the dependency mess a little.
This means
(*) tunneling a piece of information from VCLXWindow via
the XWindowPeer::getProperty method, so
we do not need to directly call VCLXWindow.
(*) moving some formpdf code from framework "down" to vcl,
where the drawinglayer code can use it
Change-Id: I2c1ff3e34941b3147e66cf0a2d0fdb13293e3aa2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144341
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The highlight and highlighttext colors can be set for some
controls. So as example a selected item in a listbox can now
be paint with anothers colors then the standard blue. Controls
are: listbox, combobox, edit field and some special edit
fields like date, currency and others.
Change-Id: Iace2dd9a1a61abb7819b6c81eb0b8030912db32b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136691
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
...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>
This adds a new accessibility class 'SVTXAccessibleNumericField'
that implements 'XAccessibleValue' and reports having an a11y
role of 'AccessibleRole::SPIN_BOX'. An object of that class
is returned by 'SVTXNumericField::CreateAccessibleContext'.
Create an 'SVTXNumericField' XWindow peer for windows
of type 'WindowType::FORMATTEDFIELD'
(instead of a 'VCLXNumericField' one), so the
newly introduced accessibility class gets used for
'FormattedField'.
This way, FormattedFields are now exposed to a11y tools
as spinboxes.
Previously, since no specific accessibility class
had been implemented for VCLXNumericField (then used as
XWindow peer class for FormattedField), the
one for VCLXEdit, i.e. VCLXAccessibleEdit, was used.
While VCLXNumericField implements XNumericField
and thus in general offers the relevant methods to implement
an accessible class that implements XAccessibleValue as well,
it uses the Formatter from the VCLXFormattedSpinField base class
to get/set values. However, that doesn't work for the FormattedField
case, since FormattedField has its own formatter of a different
type and the 'mpFormatter' member in the VCLXFormattedSpinField
base class is a nullptr, resulting in the corresponding
getter methods always returning 0 and the setters doing nothing.
With this commit in place, Accerciser now reports role
"spin box" instead of just "text" for FormattedFields
and displays the current value as well as allows to change
it via the "Value" interface when using the qt5/kf5 VCL plugin.
Note: For non-integer values, Accerciser doesn't show the actual
decimal value, but an integer, e.g. when the value for "Height"
spinbox in Writer's "Page Style" -> "Page" dialog (section "Paper
format") is set to "29.70cm", Accerciser shows "30" instead of
"29.70", despite 'Qt5AccessibleWidget::currentValue' returning
the exact value. This is because Accerciser appears to rely
on the value for the minimum increment being reported (as a
corresponding decimal value) by a call
to 'atspi_value_get_minimum_increment', s.[1].
However, there is currently no corresponding method in the
'XAccesibleValue' interface for that at-spi method which
'Qt5AccessibleWidget::currentValue' could call to retrieve
the value.
The NVDA screen reader on Windows now also says e.g.
"Width: (Type = 344) spin button editable Alt+W selected 8.50″"
instead of "Width: (Type = 344) edit Alt+W selected 8.50″".
[1] https://developer.gnome.org/libatspi/stable/libatspi-atspi-value.html#atspi-value-get-minimum-increment
Change-Id: I8af326c2d24c1801147a56ea2e2a886ab42ac634
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119590
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
used
git grep -lw namespace
| xargs perl -i -p0e 's/(\w+)\s*.\{.\s*namespace\s*(\w+)/\1::\2/smg;'
to do the initial replace, then compiled and fixed.
Change-Id: If69904d75940c851aeffab0e78c4ba02cc968d44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Mark some stuff SAL_DLLPUBLIC_RTTI in
include/vcl/metaact.hxx
in order to make ASAN happy.
Change-Id: I97febe0968bf58b9cbe60ce647f0ada25e6f4bb0
Reviewed-on: https://gerrit.libreoffice.org/84202
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ib49e2f29daa6d9b2a8195915c4ba10a8cef965ce
Reviewed-on: https://gerrit.libreoffice.org/78722
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Replace with UNO3_GETIMPLEMENTATION* macros.
Replace single usage of IMPL_XUNOTUNNEL_MINIMAL with it's body.
Change-Id: I7d4ad76399b999ebb2178ecf57edcf6bd2aa6c3e
Reviewed-on: https://gerrit.libreoffice.org/73424
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Gabor Kelemen