summaryrefslogtreecommitdiff
path: root/include/toolkit
AgeCommit message (Collapse)Author
12 days[API CHANGE] a11y: Drop UNO service to create a11y contextsMichael Weghorn
Drop the com.sun.star.accessibility.GetStandardAccessibleFactoryService UNO service that was used to create instances of the a11y classes for (mainly vcl) widgets. The service was needed to break a dependency cycle. However, with Change-Id: Ib46c87446dc9121d3b8e735e0e5a40594da73cc5 Author: Michael Weghorn <m.weghorn@posteo.de> Date: Tue Dec 17 12:04:04 2024 +0100 a11y: Merge accessibility module into vcl and all the preparatory commits in place, there is no more dependency cycle, as the a11y classes for vcl widgets no longer depend on any modules "above" vcl. Therefore, drop the UNO service and the abstract vcl::IAccessibleFactory class and other related classes. Make all methods in the AccessibleFactory class (that was previously subclassing the abstract IAccessibleFactory) static helper methods, and call them directly. The UNO service dropped in this commit was introduced in commit 1af510e95147374e5289ae1c12f1f280931919f4 Date: Wed Feb 21 11:30:47 2024 +0200 Create an UNO service to do the symbol lookup in toolkit::AccessibilityClient and its documentation was already clearly stating that it's only meant for LibreOffice internal use: > /** > The toolkit module uses this to get a pointer to the AccessibleFactory from the acc module. > Because we have a dependency in our modules that goes the "wrong" way. > > @since LibreOffice 24.8 > > @internal > > ATTENTION: This is marked <em>internal</em> and does not > have the <em>published</em> flag, which means it is subject to > change without notice and should not be used outside the LibreOffice core. > */ Change-Id: Ib97396a4bad486d9530361dd851ad3ee0f9681b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178689 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
12 daysa11y: Merge toolkit::IAccessibleFactory into vcl oneMichael Weghorn
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>
2024-12-13a11y: Move VCLXAccessibleComponent from toolkit to vclMichael Weghorn
After commit 168512dce7f1f1453c045584d47bd78a0a6c73f7 Author: Michael Weghorn <m.weghorn@posteo.de> Date: Thu Dec 12 18:06:13 2024 +0100 a11y: Stop using VCLXWindow in vcl a11y classes and further related commits, VCLXAccessibleComponent no longer depends on anything in the toolkit module, so move it from there to vcl. This way, subclassing VCLXAccessibleComponent (as the a11y classes for vcl widgets do, currently located in accessibility/ ) no longer introduces a toolkit dependency. Change-Id: I4fd33fb1dc2265d75e8ca9ad87bcc70db61639d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178434 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-12-12a11y: Stop using VCLXWindow in vcl a11y classesMichael Weghorn
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
2024-12-12a11y: Rename VCLXAccessibleComponent::m_x{EventSource -> Window}Michael Weghorn
Change-Id: I3724481e81a5f2987567b51424da479879ca78ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178364 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-12-05a11y: Drop SAL_LOPLUGIN_ANNOTATE("crosscast")Michael Weghorn
Added in: commit d66a97d5622bfc7c8d68452eb5a3c2378b0b1820 Date: Thu Jan 12 08:29:24 2023 +0100 loplugin:crosscast (clang-cl) > winaccessibility/source/service/AccTopWindowListener.cxx(47,36): error: suspicious dynamic cross cast from 'css::accessibility::XAccessible *' to 'VCLXAccessibleComponent *' [loplugin:crosscast] > else if (auto pvclxcomponent = dynamic_cast<VCLXAccessibleComponent*>(pAccessible)) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change-Id: Iee7585dd2fa0d92af3be6b89d7d08326de3d1e7b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145380 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> AccTopWindowListener::HandleWindowOpened no longer does that crosscast now, see Change-Id: Ic96d2c95128af144c7769aac40707299b1c80f8c Author: Michael Weghorn <m.weghorn@posteo.de> Date: Thu Dec 5 14:07:52 2024 +0000 tdf#164093 tdf#157001 wina11y: Use vcl::Window's actual XAccessible Change-Id: Ifca76a5d519099f9cbe06f8bde606e01871363fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177891 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-12-04a11y: Move menu a11y classes to vcl, no more use factoryMichael Weghorn
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>
2024-12-04Move helpers for css::awt/VCL point/rect/size to vcl::unohelperMichael Weghorn
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>
2024-12-04[API CHANGE] a11y: Drop XAccessibleExtendedComponent::getFontMichael Weghorn
This method from the unpublished XAccessibleExtendedComponent interface is not used by any of the a11y platform bridges, and I don't know of any platform a11y API that would need it. In order to report character/font attributes, there is the XAccessibleText interface and its XAccessiText::getCharacterAttributes method instead, which actually gets used by the platform a11y bridges. Therefore, drop this method to simplify code, and also decouple the accessibility module a bit further from the toolkit module without having to reorganize code further. (VCLXFont from the toolkit module currently gets used in various implementations.) Change-Id: I06ea3cc5998a13927b3f869877b28f03ac07c89b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177809 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-12-04toolkit: Pass VCLXFont init args in ctorMichael Weghorn
Pass arguments right away in ctor rather than having a ctor that takes no arguments and then having to call VCLXFont::Init with the arguments right after calling the ctor. Change-Id: I651e27154499f61638409377438f9589bc7412a3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177795 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-12-04Use '#pragma once' in vclxfont.hxxMichael Weghorn
Change-Id: I445ec8a08c6622c681e459efc2dd2afbf74dd78e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177794 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-11-07Make sure VCLXPopupMenu has unique RTTIStephan Bergmann
...by providing a non-inline key function for that class. This would have prevented the issue that has been addressed by 2fe53b2e436cb236b2dc121ceec4f22de49a13a8 "Fix crash due to unexpected dynamic_cast failures in optimized build", where a dynamic_cast to VCLXPopupMenu failed on macOS (which uses pointer equivalence to determine RTTI equivalence), because VCLXPopupMenu is final, so the compiler, at least in optimized builds, just used a comparison between the object's recorded RTTI (from dylib A) against the type's RTTI in dylib B, which erroneously failed. Change-Id: I68ff864c266bf28d19032527f91de592ca1437f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176188 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-07-11Unify/Port to use VCLUnoHelper for AWT <-> VCL conversionsMichael Weghorn
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>
2024-07-11VCLUnoHelper: Align AWT <-> VCL helpers with convert.hxx implMichael Weghorn
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
2024-06-11Some missing "block untrusted referer links" for form controlsStephan Bergmann
...where "Referer" is now passed in as an additional property, so that the relevant objects can decide whether to obtain graphics while loading a document Change-Id: Ie3dabc574861713212b906a0d7793f438a7d50a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168674 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-28Extended loplugin:ostr manual changesStephan Bergmann
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
2024-03-02add UNLESS_MERGELIBS_MORE and use to reduce symbol visibilityNoel Grandin
Change-Id: I2e6c2dcd06c76e0f5f68a1debde3a20665104b27 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164219 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-22UBSan RTTI fixesNoel Grandin
after I missed a bunch of stuff when testing UBSan with commit 3ba92b5f1eaf7d4447a0943ea260db515ca799dc hide more symbols Change-Id: Id3cb0b70b9fa24c7e3fba7fd565eb658dafa00f8 Change-Id: I369587ed3e14e50ca272037b9d950b62841695d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163703 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-19hide more symbolsNoel Grandin
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>
2023-11-06tdf#146619 Recheck include/t* with IWYUGabor Kelemen
Change-Id: I005257e458351285b1b35ffe49c8b42834a6db68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156990 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-09-01tdf#104833 a11y: Use VCLXAccessibleEdit for VCLXMultiLineEditMichael Weghorn
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>
2023-09-01tdf#104833 Move VCLXMultiLineEdit to public toolkit headerMichael Weghorn
This is in preparation of having the a11y factory create a proper accessible context for it. Change-Id: If60efa84263c2d68eb57daa3aae4834a060529c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156401 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2023-08-02split Point/Size/Rectangle into AbsoluteScreenPixel* typesNoel Grandin
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>
2023-05-09move a toolkit header inside the moduleNoel Grandin
It is only used inside the module, no need to be public Change-Id: Ibd8445ecbb67624569ee7225f0bdf6d9c041dab4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151569 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-12Revert "remove unnecessary UnoControlModel::setPropertyValues"Noel Grandin
This reverts commit 19c18c94085f7a70e536a914ed978fc54b5625b9. Because it breaks the MRI extension, I was wrong, it does not do quite the same thing as its superclass method. Change-Id: I65bfb4264615dea5f6d0f2fb7b989352e7e83ee1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150274 Tested-by: Justin Luth <jluth@mail.com> Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-10use std::unordered_map for static properties in toolkitNoel Grandin
which is faster than binary lookup Change-Id: Ia810313af36c75fd9b5b241704f0cbd66afcb6b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150189 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-01pack the UnoControlComponentInfos structNoel Grandin
Change-Id: I18ab490074051831dd31b3953308e372ca2b469f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149904 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-01use more XVclWindowPeerNoel Grandin
Rather than using it's superclass XWindowPeer and implicitly relying on it being XVclWindowPeer and casting it everywhere. Change-Id: Icfb46f3b920d00f4a167a31803a71bbb0368d05c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149894 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-03-31simplify subclasses of comphelper::OPropertySetHelperNoel Grandin
they should deal in terms of the fast property IDS, they should not need to override setPropertyValueImpl, so just remove this, and standardise on the subclasses overriding setFastPropertyValueImpl Change-Id: I190955ccc4ae3e07dd481a1044f3c074dd1a40aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149836 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-03-31remove unnecessary UnoControlModel::setPropertyValuesNoel Grandin
which does exactly the same thing as the method it overrides Change-Id: Ib227011795f0cf6336fb1e01c14636a9996bb164 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149835 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-03-13convert UnoControlModel and friends to use std::mutexNoel Grandin
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>
2023-03-08deduplicate MutexAndBroadcastHelperNoel Grandin
there are two very similar classes, standardise on the one in include/comphelper Change-Id: If85729dcea01e65a2d095bb211fe643c783ebf1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148442 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-22BaseMutex->std::mutex in ListenerMultiplexerBaseNoel Grandin
Change-Id: Icd565c83ca3b4afb1a846a637b7943b0498487e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147457 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-25Use ImplInheritanceHelper in VCLXAccessibleComponentStephan Bergmann
Change-Id: I300f033054bddc2c0ee1973dbafc108c477bf09a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146103 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-14XUnoTunnel->dynamic_cast in VCLXMenuNoel Grandin
Change-Id: Iee992e2e09647a7678fd05321e601a4c5bf0c430 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145469 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-14XUnoTunnel->dynamic_cast in UnoControlModelNoel Grandin
Change-Id: I0d8a65aa16583fcb6c8201589b2d356da0be5cac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145482 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-13XUnoTunnel->dynamic_cast in VCLXFontNoel Grandin
Change-Id: I4afa34805e64f3ff37b76fe8ca4676c1f4eb3e14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145468 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-13XUnoTunnel->dynamic_cast in VCLXDeviceNoel Grandin
Change-Id: I9fa06600d3b9a2172a1818f89a3b9c06d65c8c54 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145467 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-12loplugin:crosscast (clang-cl)Stephan Bergmann
> winaccessibility/source/service/AccTopWindowListener.cxx(47,36): error: suspicious dynamic cross cast from 'css::accessibility::XAccessible *' to 'VCLXAccessibleComponent *' [loplugin:crosscast] > else if (auto pvclxcomponent = dynamic_cast<VCLXAccessibleComponent*>(pAccessible)) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change-Id: Iee7585dd2fa0d92af3be6b89d7d08326de3d1e7b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145380 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-10OAccessibleImplementationAccess was apparently effectively unused by nowStephan Bergmann
...as there were no calls to its OAccessibleImplementationAccess::getUnoTunnelId so no code apparently made use of that XUnoTunnel Change-Id: I35d392999f1c28e81f7ff4bf395f63642eb17bce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145250 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-09Clean up VCLXAccessibleComponent::getAccessibleParentStephan Bergmann
...after 21e0d8162a0e683558c4d042ce688fc9a6833809 "loplugin:unusedfields" had dropped the base class OAccessibleImplementationAccess::implGetForeignControlledParent Change-Id: I753aad41baaa0ac1d1f7eb0a6084993df5a58d5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145197 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-05Revert all the recent loplugin:unocast changesStephan Bergmann
...as obsoleted by ef533553559fe09b4afab651fc692885d1acf4ed "Rudimentary support for dynamic_cast on UNO proxy objects". This reverts all of: 4cfcc9ac37b90ce64c8402a41eb4638adb185b5c "loplugin:unocast (framework::Desktop)" 03efbf72f4ddf7a84aa8aabef348331bd4b75e8a "loplugin:unocast (vclcanvas::TextLayout)" 80099fdd51a69eaa6c36ca88ef772810e4a777fa "loplugin:unocast (SalGtkXWindow)" cc147f576d8687fb79c77d47d41dc4ba1678a469 "loplugin:unocast (sdext::presenter::CachablePresenterView)" 40db42be1d8fd0f9c6c8c5ba3767ddb9ee2034c2 "loplugin:unocast (vclcanvas::CanvasFont)" 2d1e7995eae29e2826449eb5179f5fae181794a5 "loplugin:unocast (CairoColorSpace)" 4c0bbe4bd97636207cf71a6aa120c67698891da9 "loplugin:unocast (canvas::ParametricPolyPolygon)" 89803666621c07d1b1ac9d3bd883f0ca192a91a0 "loplugin:unocast (vclcanas::CanvasBitmap)" d5e0c2c8db71878d21c2a7255af08cf5f9a6dd04 "loplugin:unocast (sfx2::DigitalSignatures)" c0c4519e0d5b555f59bbc04cc616454edfd1f4ce "loplugin:unocast (VCLXAccessibleComponent)" feb8b833a6245d42400f42a0bc789dc84594ee6f "loplugin:unocast (VCLXDialog)" 1fa58cc6cc9c3849753342a5d9a6ddfa461b5e66 "loplugin:unocast (VCLXMultiPage)" f481f036deb1b1b46f3038074c4659f3a91b9c6c "loplugin:unocast (DocumentSettingsSerializer)" 73df933f5fa5932f94e5a1b338a3eda00a9ce354 "loplugin:unocast (css::embed::EmbeddedUpdate)" 420165ab0ef03c0467f9d17f504de2d2fc78f0e6 "loplugin:unocast (canvas::tools' StandardColorSpace, StandardNoAlphaColorSpace)" 9abe8ee067e6c00f19d8a13346d53c4641c27166 "loplugin:unocast (MutableTreeNode)" 9f3022ceb036f23b4b0994c3e2fbd1001bff225a "loplugin:unocast (VCLXTabPage)" 1be70dda02c12a60778b7607cff2520ae1aa611e "loplugin:unocast (vcl::unotools::VclCanvasBitmap)" d6a70bb641b96e8e5616448c2378131ed62658b4 "loplugin:unocast (basegfx::unotools::UnoPolyPolygon)" 5a14f009e6782c077463c8cbb8e9cea3d7950107 "loplugin:unocast (xmlsecurity::Certificate)" 99009c9535dfa3e0d838989ccc7d84bfa2320ff4 "loplugin:unocast (sd::Annotation)" 0c7585c5fa78887e5459885ed744e8044fd76137 "loplugin:unocast (sd::TextApiObject)" 24e14afd1bfcaed6c200ab081973fba7e47267ca "loplugin:unocast (SignatureVerifierImpl)" 1a7ad0c10d286ce9ae2700ceb2fd50eed1fb43a4 "loplugin:unocast (pcr::PropertyEventTranslation)" a97e2d2702d9a6f37775ccee2c08c4f3b2479c4b "loplugin:unocast (RangePageBreaks)" 19dfdf86ad1f5b08041d8b7a9f196caf881231ab "iloplugin:unocast (pcr::OFormattedNumericControl)" f9785ea595fd8e911f6370e836fa579225b9e571 "loplugin:unocast (frm::OInterfaceContainer)" 5e5f40a4a92a31b0932c690219d002fcf18598cf "loplugin:unocast (ScVbaShapes)" 27b35b2c215b4832d4378ec3a7ecbba926552d06 "loplugin:unocast (ScVbaShapeRange)" cb3108f860065928552a86cf8acc4b3a95718ecf "cid#1517812 Dereference null return value" feba0ddb1521d1142560fe54b7d7696ee910237f "loplugin:unocast (weld::TransportAsXWindow)" 4d6c23216559eb48f9943bb49d6e475a6d64ba15 "loplugin:unocast (oox::ForumlaImExportBase)" 4844c096a8ab6a9a620c410a0949d4499f12a504 "loplugin:unocast (cairocanvas::SurfaceProvider)" 9a0b523e0a84d403b9092176ccec4b3e3efe42d0 "loplugin:unocast (cairocanvas::CanvasBitmap)" 8a5648d8e59b4b007dbbf3824777c19a21efc61e "loplugin:unocast (cairocanvas::TextLayout)" 28c27a0623bc78a0590858f97d03b620985bc84c "loplugin:unocast (cairocanvas::CanvasFont)" 53bc223cb3288e32a417696ee61c29e5f01f209d "loplugin:unocast (cairocanvas::RepaintTarget)" 5f70b0b9f6bc4ab145ddbd9155590ed4a3b1b9ec "loplugin:unocast (SvXMLImport)" 068187a898cdd2e26e9b16c348ecc1ed2dee3f29 "loplugin:unocast (VCLXWindow)" 88b4f966202717cd4ad38a30a8eda22c3e69ed35 "loplugin:unocast (sfx2::sidebar::SidebarController)" f1b7a69b280aefe2f1b3b0f32193494fd765f2bd "loplugin:unocast (SvxLineStyleToolBoxControl)" ba76f0ba7e8de4d2953739c952004b7d9af47197 "loplugin:unocast (i18npool::Calendar_gregorian)" 840154daf934d8df52ead1cb7acd798c4d30f007 "loplugin:unocast (framework::AddonsToolBarWrapper)" b0e9c4c5f063cefa9557810e3349bdb9c7493091 "loplugin:unocast (GrammarCheckingIterator)" 8ee6cfc9655ce9de4617cea1a0d9cb9d7a4fbfac "loplugin:unocast (ucb::ucp::ext::Content)" 5b8cd77c112bc8c0e92b8fec215c3c8e802bbc0a "loplugin:unocast (basic::SfxScriptLibraryContainer)" 9e73ff9fce12e102bb3c3cea8d8bb96c88f2c9ad "loplugin:unocast (sdext::presenter::PresenterNotesView)" a98acca8fbc38d3fd5600ae5056a8e42b6d8a40d "loplugin:unocast (SelectionChangeHandler)" c0b59ad6e35b0cb0dea0821e95f95569739078c1 "Consistently use comphelper::getSomethingImpl<I>(aIdentifier, this)" 276e3ccbdd3259ec3daf8a1a98fa7f406b14e21c "loplugin:unocast (vclcanvas::RepaintTarget)" Change-Id: I37c73e3422a5154bf6cb647640d2d3f23db8bc34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145063 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-23loplugin:unocast (VCLXAccessibleComponent)Stephan Bergmann
(See the upcoming commit introducing that loplugin:unocast on why such dynamic_casts from UNO types are dangerous.) Change-Id: I11496cc1d37e89ce8f11991f86c7b60bb1b93106 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144748 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-19remove dependency from drawinglayer to frameworkNoel Grandin
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>
2022-12-01loplugin:unusedfields make some fields privateNoel Grandin
Change-Id: Ia30e3b7f10ae11c7a74e6860ac0a6115caaa439f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143529 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-12-01Use cppuhelper::ImplInheritanceHelper for toolkit VCLX window classesStephan Bergmann
Change-Id: I102b49608b62b351d6a458b3fd56167b136b24e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143525 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-19loplugin:unusedmethodsNoel Grandin
Change-Id: I5dcba14a9b0dfcc5267760410f6d135fcd3b1bd2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142944 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-09-19tdf#149797 Change highlight background color in some controlsIlhan Yesil
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
2022-09-02[API CHANGE] tdf#150683 a11y: Switch a11y child index to 64 bitMichael Weghorn
With 16k column support in Calc enabled by default in commit 4c5f8ccf0a2320432b8fe91add1dcadf54d9fd58 Date: Tue Mar 8 12:44:49 2022 +0100 change default Calc number of columns to 16384 (tdf#50916) , the number of Calc cells in a spreadsheet is larger than SAL_MAX_INT32, meaning that a 32-bit a11y child index is no more enough and using it resulted in integer overflows in methods handling corresponding Calc cells in the a11y layer. This e.g. had the effect of the Orca and NVDA screen readers not announcing focused or selected cells properly when their a11y child index was out of the 32-bit integer range. Switch the internal a11y child indices to 64 bit to be able to handle this properly internally. Since the platform APIs (at least AT-SPI on Linux and IAccessible2 on Windows; from what I can see LO's macOS a11y bridge doesn't directly expose the child index) are still restricted to 32 bit, larger child indices still cannot be exposed via the platform APIs. As a consequence, use of the the IAccessible2 and AT-SPI methods that use the child index remains problematic in those cases where the child index is larger. However, as an alternative to using the AT-SPI Table interface and the IAccessibleTable/ IAccessibleTable2 interfaces with the child index to retrieve information about a specific cell, both AT-SPI and IAccessible2 also provide interfaces to retrieve that information directly from the cell object (TableCell interface for AT-SPI, IAccessibleTableCell for IAccessible2). Those interfaces are already implemented/exposed for winaccessibility (s. `CAccTable`) and the qt5/qt6/kf5 VCL plugins (s. the `QAccessibleTableCellInterface` methods implemented in `QtAccessibleInterface`). With the switch to 64-bit internal a11y child indices, these now behave correctly for cells with a child index that doesn't fit into 32 bit as well. NVDA on Windows already uses the IAccessibleTableCell interface and thus announcing focused cells works fine with this change in place. Orca on Linux currently doesn't make use of the AT-SPI TableCell interface yet, but with a suggested change to do so [1], announcement of selected cells works with the qt6 VCL plugin with a current qtbase dev branch as well - when combined with the suggested changes to implement support for the AT-SPI TableCell interface in Qt [2] [3] and the LO change based on that [4] and a fix for a nullptr dereference [5]. The gtk3 VCL plugin doesn't expose the AT-SPI TableCell interface yet, but once it does so (via `AtkTableCell`), it also works with the suggested Orca change [1] in place. (Adding that is planned for an upcoming change, works with a local WIP patch.) For handling return values that are larger than what platform APIs support, the following approach has been chosen for now: 1) When the return value is for the count of (selected) children, the maximum value N supported by the platform API is returned. (This is what `ScAccessibleTableBase::getAccessibleChildCount` did previously.) The first N elements can be accessed by their actual (selection) indices. 2) When the return value is the child/cell index, -2 is returned for objects whose index is greater than the maximum value supported by the platform API. Using a non-negative value would mean that the index would refer to *another* actually existing child. A child index of -1 on the other hand tends to be interpreted as "child is invalid" or "object isn't actually a child of its (previous) parent any more)". For the Orca case, this would result in objects with a child index of -1 not being announced, as they are considered "zombies" [6]. What's still somewhat problematic is the case where more than 2^31 children are *selected*, since access to those children still happens by the index into the selection in the platform APIs, and not all selected items are accessible this way. (Screen readers usually just retrieve the first and last element from the selection and announce those.) Orca already seems to apply different handling for the case for fully selected rows and columns, so "All cells selected" or "Columns ... to ... selected" is announced just fine even if more than 2^31 cells are selected. (Side note: While Microsoft User Interface Automation - UIA - also uses 32-bit indices, it also has specific methods in the ISelectionProvider2 interface that allow to explicitly retrieve the first and last selected item, `ISelectionProvider2::get_FirstSelectedItem` and `ISelectionProvider2::get_LastSelectedItem`, but we currently don't support UIA on Windows.) Bound checks at the beginning of the methods from the `XAccessibleContext`, `XAccessibleSelection` and `XAccessibleTable` interfaces that take a child index (or in helper methods called by those) should generally already prevent too large indices from being passed to the methods in the lower layer code that take smaller integer types. Such bound checking has been been added in various places where it wasn't present yet. If there any remaining issues of this kind that show after this commit, they can probably be solved in a similar way (s.e.g. the change to `AccessibleBrowseBox::getAccessibleChild` in this commit). A few asserts were also added at places where my understanding is that values shouldn't be larger than what is supported by a called method anyway. A test case will be added in a following change. [1] https://gitlab.gnome.org/GNOME/orca/-/merge_requests/131 [2] https://codereview.qt-project.org/c/qt/qtbase/+/428566 [3] https://codereview.qt-project.org/c/qt/qtbase/+/428567 [4] https://gerrit.libreoffice.org/c/core/+/138750 [5] https://codereview.qt-project.org/c/qt/qtbase/+/430157 [6] https://gitlab.gnome.org/GNOME/orca/-/blob/82c8542002e36e0d3d918088d583162d25136143/src/orca/script_utilities.py#L5155 Change-Id: I3af590c988b0e6754fc72545918412f39e8fea07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139258 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-08-18Move tools/diagnose_ex.h to comphelper/diagnose_ex.hxxStephan Bergmann
...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>