Re: [Lazarus] LCL and Lazarus Accessibility - restarting the discussion
My accessiblity work for Cocoa/Qt5 has been submitted as a patch in bugtracker 38603 On 3/5/21 10:44 AM, Marco Zehe via lazarus wrote: Hi David! Wow, that sounds exciting! Look forward to your patch. I did some digging, and found that on Windows, TTreeView does not create any handles at all yet. It would require at least some basics there, or even accessibility properties, but I am still hoping we can avoid what I had to do for TVirtualStringTree in 2007, implementing literally two IAccessible interfaces, one for tree, one for the focused tree item. That all was managed by a singleton class instance, and juggled quite a bit. Pretty unreliable, so I hope we can make it better in TTreeView for the LCL. Right now, however, I don’t even know where to start yet to implement this. There is a unit in the Win32 folder, but nothing in there besides the comments. And from what it sounds like, it makes sense to wait for your patch so I, or we, can then build on that and make the Windows implementations better. Marco -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LCL and Lazarus Accessibility - restarting the discussion
On 3/5/21 10:44 AM, Marco Zehe via lazarus wrote: Hi David! Wow, that sounds exciting! Look forward to your patch. I did some digging, and found that on Windows, TTreeView does not create any handles at all yet. It would require at least some basics there, or even accessibility properties, but I am still hoping we can avoid what I had to do for TVirtualStringTree in 2007, implementing literally two IAccessible interfaces, one for tree, one for the focused tree item. That all was managed by a singleton class instance, and juggled quite a bit. Pretty unreliable, so I hope we can make it better in TTreeView for the LCL. Right now, however, I don’t even know where to start yet to implement this. There is a unit in the Win32 folder, but nothing in there besides the comments. And from what it sounds like, it makes sense to wait for your patch so I, or we, can then build on that and make the Windows implementations better. Marco For any tree type objects that I have dealt with (both LCL and custom) I have created Ax objects for the tree and Ax objects for the items as well. And in cocoa I had to create an additional layer: Tree/Row/Item in Row. A couple of deficiencies that I have run across with the LCL accessibility layer are 1) No notification capability both Cocoa and Qt include functionality to send notifications to Ax Clients to let them know of changes to the UI 2) TLazAccessibleObject handle creation doesn't sync well with TLazAccessibleObject.Ownercontrol handle creation. Both Cocoa and Qt include accessibilty support in their base widgets that can be leveraged as TlazAccessibileObject handles. But TLazAccessibleObject will request a handle before the associated TWinControl has handleallocated and doesn't know to retry for a handle after the TWinControl get's its handle. It would be good to include a path where TLazAccessibleObject handle is requested after the TWinControl.Handle is created. I will note that reading the comments surrounding the TLazAccessibleObject code in Controls and control.inc are important. I made a couple of bad assumptions about how the code worked before I read all the comments. The first was that TLazAccessibleObject.Children objects are not meant for TControl or TWinControl objects. They are only for visual items that don't have a TControl or TWinControl object. E.g. row items in a tree view. And the difference in getting children by either using the iterator or doing First / Next. The iterator returns the objects in the child tree only. First / Next will get the objects from the child tree but also any TControls that are in the ownercontrol.Controls() array. The latter allows code to find ALL the children - visual only and TControl objects. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LCL and Lazarus Accessibility - restarting the discussion
Hi David! Wow, that sounds exciting! Look forward to your patch. I did some digging, and found that on Windows, TTreeView does not create any handles at all yet. It would require at least some basics there, or even accessibility properties, but I am still hoping we can avoid what I had to do for TVirtualStringTree in 2007, implementing literally two IAccessible interfaces, one for tree, one for the focused tree item. That all was managed by a singleton class instance, and juggled quite a bit. Pretty unreliable, so I hope we can make it better in TTreeView for the LCL. Right now, however, I don’t even know where to start yet to implement this. There is a unit in the Win32 folder, but nothing in there besides the comments. And from what it sounds like, it makes sense to wait for your patch so I, or we, can then build on that and make the Windows implementations better. Marco -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LCL and Lazarus Accessibility - restarting the discussion
Marco (and others) I have been working on implementing Accessibility for Cocoa and Qt5. Mostly I have been working in the lcl/interfaces/cocoa and lcl/interfaces/qt5 directories creating the widget level plumbing needed to interface with TLazAccessibleObject. However, I have made a few fixes and changes to TLazAccessibleObject as well. I have fixed access to the child tree so that it is actually dataobject sorted so that the search functions work. And I have added a accessibilityName field to work with accessibilityDescription, accessibilityRole, and accessibilityValue. In Cocoa this matches the accessibile Title and in qt it matches accessibile Name. Both Qt and Cocoa have an accessibleDescription field but it does not map well to the laz accessibleDescription which is being used the same way the Qt and Cocoa use the Name/Title field. My Cocoa implementation is well developed and gives us access to all parts of our app that isn't custom (though I am able to add our custom objects as well - just haven't got all of them yet). The Qt5 implementation is fairly basic yet. It does all native controls and also a base implemenation of TCustomTreeView. I intend to clean up what I currently have and submit as a patch within the next weeks. David Jenkins -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
