Broadcasting may call back into this, from
TreeControlPeer::updateNode().
Release maMutex before broadcasting to fix it.
(regression f7ee6baa1b)
Change-Id: I91a8e043aaed02422601e5d4d5253379abab5d7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120616
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The change allowed to simplify many places where previously this API was
used, to avoid inefficient calculations (e.g., moving rectangle keeping
its size, and then immediately changing the size).
Change-Id: Ica2dc594d91cae83e2c2740c1f4fb23f44998916
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120461
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
in a handful cases, like a map or a vector, we don't need init on demand
at all, the default constructor can be laid out at compile time
Change-Id: I2d404584b5aa23db7b1f779e160e04e72dd2aa74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119656
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
As found when debugging tdf#143534 "Crash in Calc NLP Solver when saving
a document in Write" on Linux x86-64 (where tools::Long is 64-bit long; while
UNOIDL LONG is 32-bit): These ImplSetPropertyValues cause
comphelper::OPropertyContainerHelper::convertFastPropertyValue to throw via
lcl_throwIllegalPropertyValueTypeException due to the mismatch---which were then
silently caught in UnoDialogControl::windowResized resp.
UnoDialogControl::windowMoved.
Change-Id: I9793204ad49737165e69de7d5e15445ba0e82c85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119535
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
VCLXToolkit::createSystemChild() doesn't init WindowImpl::mpVCLXWindow
and so it can happen that another VCLXTopWindow instance is created
later for the same Window.
Change-Id: I9ac654dceb15ea619597f2b8d9d1f9282aa1dfc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118684
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
commit 2a694f9e0e
Date: Wed May 6 14:08:07 2020 -0400
lok: fix the window type of the formatted field control
had introduced the new 'WindowType::FORMATTEDFIELD' and set
it for the 'FormattedField' control (instead of using
the previous default value set in the 'SpinField' ctor,
which is 'WindowType::SPINFIELD').
So far, this type was not explicitly handled when
creating the XWindow peer.
Handle it just the same as 'WindowType::SPINFIELD'
and return a new 'VCLXNumericField', which e.g.
makes sure that a "proper" accessible is created
and thus alues of a spin field are announced by
the NVDA screen reader (again).
(See also
commit 33cac418db
Date: Fri May 29 16:53:59 2020 +0200
tdf#133498 Make native drawing of FormattedField work (again)
which had fixed a similar regression elsewhere.)
Change-Id: Ie8a4d279a12a1b83a9cf97f1304d84214b3a2a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118568
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
caused by
commit 883b7a34d2
DBG_ASSERT->assert in UnoWrapper
No idea why X-ray is triggering this, but it seems to work when I dial
it back to a SAL_WARN again
And also caused by
commit 5aa60be574
fix leak in VCLXWindow
So disconnect the toolkit-window-peer from the vcl::Window before
disposing the peer.
Change-Id: I3310b76c1affc13c53c1e23810e383a8d2152ec7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115806
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
as part of a longer-term goal of doing our
widget rendering only inside a top-level render-
context.
I moved all of the OutputDevice-related code that existed in vcl::Window
into a new subclass of OutputDevice called WindowOutputDevice.
Notes for further work
(*) not sure why we are getting an 1x1 surface in
SvpSalGraphics::releaseCairoContext, but to fix it I clamp
the size there
(*) might have to dump VCLXDevice, and move it's code down into VCLXWindow and VCLXVirtualDevice
(*) can we remove use of VCLXDevice in other places, in favour of just talking to the VCL code?
Change-Id: I105946377f5322677d6f7d0c1c23847178a720b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113204
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
regression from
commit 5aa60be574
fix leak in VCLXWindow
it's too dangerous to dump the Impl during dispose(), because if I do,
the Impl is removed while we are iterating over listeners.
So just be check mbIsDisposing more heavily to prevent new references to
the VCLXWindow being added after it is disposed.
Change-Id: Ibb00a289440d24f531072ef5809613d5e8a0a98f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115598
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Noel Grandin