Hello,I am not sure this is something we can do or how far we'd like to go to make the plugins API similar.
For example on linux we do have at-spi thus when dealing with UI controls orca uses at-spi directly.
NVDA implements several accessibility APIs (MSAA, IA2 on top of it, java access bridge and UIA). It generalizes all the APIS in its own super class called NVDAObject. Are we able to accept such a layer into orca?
Now we are shaping next part of orca plugin venture, so perhaps we might take a look on how they are exposing ability to add app specific modules, perhaps this part might become similar, although in practice it's just a way on how to instantiate various NVDAObject subclasses depending on which app is active.
Then there are synthDrivers. NVDA's synthDriverHandler is different to orcas SpeechServer. Various TTS engines are platform specific anyway, so do we want to spend development resources in making these APIs similar?
Then there are NVDA addons that are not enhancing screen reader experience but are adding various other features e.g. checking system resources, weather, translation services and similar. In terms of implementation NVDA Remote would also fit into this category. They are more or less hooked into NVDA's UI which you know is written with wxpython. wxwidgets is not verry accessible on linux so taking this route is not worth for orca either.
If our goal is to ease addon development for both orca and NVDA addon authors then it might be possible to come up with enhancements however if you are looking to run the same addons under both orca and NVDA, I would say this is very unlikelly to work.
Greetings Peter Dňa 11. 6. 2021 o 3:44 Alexandro Jurgensen via orca-list napísal(a):
Hi, It would be great if NVDA/Orca could grow together, at least in API, to ease plugin development over time. Warm regards, Alex Alex Jurgensen, He/Him/His I wear many hats! Lead Software Developer, Bowen Innovations Research and Development Society www.birdsonbowen.com President Camp Bowen Society for the Independence of the Blind and Deafblind www.campbowen.ca Lead Program Coordinator Pacific Training Centre for the Blind www.ptcb.caOn Jun 10, 2021, at 6:13 PM, Andy Borka via orca-list <orca-list gnome org> wrote: Considering that Orca and NVDA are both written in Python 3, this concept of sharing addons between Orca/NVDA might be possible. The only trick is determining what screen reader is involved, then enabling/disabling the API for each one. When I get up and running, will take a look. -----Original Message----- From: orca-list <orca-list-bounces gnome org> On Behalf Of Linux A11y Sent: Thursday, June 10, 2021 7:48 PM To: Alexandro Jurgensen <voiceovertrainer me com> Cc: orca-list gnome org Subject: Re: [orca-list] Pluginsystem for Orca using libpeas Howdy Alex, This is an very good idea. I thought about something similar. Sadly, I do not have many experience with NVDAs API. Maybe Andy can help out here? As far as i understand he already did some nice additions for NVDA. @Andy, maybe can create some level of compatibility? Maybe use the good, and improve the not so good concepts of NVDA in some compatible way? Cheers chrys Von meinem iPhone gesendetAm 11.06.2021 um 01:19 schrieb Alexandro Jurgensen <voiceovertrainer me com>: Hi, Then, let me propose something different. What if we made a common plugin format with NVDA, Orca, and others, os that plugins can be written once and shared. Like web browser extension, they would not be 100% portable, but could hire enough code to push the industry forward and give greater choice to users, leading to a bigger pool for developers. Warm regards, Alex Alex Jurgensen, He/Him/His I wear many hats! Lead Software Developer, Bowen Innovations Research and Development Society www.birdsonbowen.com President Camp Bowen Society for the Independence of the Blind and Deafblind www.campbowen.ca Lead Program Coordinator Pacific Training Centre for the Blind www.ptcb.caOn Jun 10, 2021, at 4:10 PM, Linux A11y <chrys linux-a11y org> wrote: Howdy Alex, well, possible is very unsharp by definition . Technically is everything possible. Depends on how many developers, time or money is spent. So the right question is does it make sense? It agree to Christopher, a lot of abstraction is required, and the backend scrips might need a complete rewrite on every Platt-form as well. even if possible, i would say its not wort to do. In that time you have created something from scratch as well and this fitts the needs even more. Just my opinion, not a rule ;). Cheers chrysAm 11.06.2021 um 00:58 schrieb Christopher Chaltain <chaltain outlook com>:Yes, I understand. My point is that I don't think it's very feasible, but that's just my $0.02. -- Christopher (AKA CJ) Chaltain at Outlook -----Original Message----- From: Alexandro Jurgensen <voiceovertrainer me com> Sent: Thursday, June 10, 2021 5:46 PM To: Christopher Chaltain <chaltain outlook com> Cc: chrys <chrys linux-a11y org>; orca-list gnome org Subject: Re: [orca-list] Pluginsystem for Orca using libpeas Hi Christopher, I wasn’t meaning to ask if you could do this work, just trying tu gauge how possible such an endeavour would be before sticking a few devs on it. We are particularly interested in an alternate Mac screen reader in addition to Linux support. :) Warm regards, Alex Alex Jurgensen, He/Him/His I wear many hats! Lead Software Developer, Bowen Innovations Research and Development Society www.birdsonbowen.com President Camp Bowen Society for the Independence of the Blind and Deafblind www.campbowen.ca Lead Program Coordinator Pacific Training Centre for the Blind www.ptcb.caOn Jun 10, 2021, at 3:39 PM, Christopher Chaltain via orca-list <orca-list gnome org> wrote: My understanding is that a lot of screen reader code is taking advantage of technologies built into and unique to each operating system, so only a limited amount of the code could be ported, and a lot of work would have to go into making this portable code work with the OS specific layers that would be needed on each platform. Just my $0.02. -- Christopher (AKA CJ) Chaltain at Outlook -----Original Message----- From: orca-list <orca-list-bounces gnome org> On Behalf Of chrys Sent: Thursday, June 10, 2021 2:55 PM To: orca-list gnome org Subject: Re: [orca-list] Pluginsystem for Orca using libpeas Howdy Alex, maybe its technically possible, but windows already has a lot of screen readers. So i will only concentrate my time to Linux. For windows its just another alternative. fur Linux its a must have without any choice currently.Am 10.06.21 um 21:21 schrieb Alexandro Jurgensen via orca-list: Hi All, I’m just throwing this out there but can this work set the stage for Orca to be ported to other operating systems? The organization I work with is interested in cross-platform screen reader technologies. If there are already separate plugins for GTK and QT apps on the table, could this pave the way for plugins based on MSAA or Apple’s AXAccessibility APIs? Warm regards, Alex Alex Jurgensen, He/Him/His I wear many hats! Lead Software Developer, Bowen Innovations Research and Development Society www.birdsonbowen.com President Camp Bowen Society for the Independence of the Blind and Deafblind www.campbowen.ca Lead Program Coordinator Pacific Training Centre for the Blind www.ptcb.caOn Jun 10, 2021, at 9:56 AM, Didier Spaier via orca-list <orca-list gnome org> wrote: Hi, I would go for: 3. Build libpeas from source. Make a package for it just took 40 seconds on my laptop. I'll leave for others to tell you how to do that for Ubuntu. Cheers, Didier Le 10/06/2021 à 18:44, Geoff Shang a écrit :On Thu, 10 Jun 2021, chrys wrote:if this commit is true, you need at least version 1.26 of libpeas from January 2020.Debian Bullseye (the next release) has libpeas 1.28. Unfortunately, it doesn't appear to be in buster-backports. I looked at the version in Bullseye. It actually has fewer dependencies than the version in Buster, and many of them are the same version or are covered by packages in Buster. However, it depends on libpython3.9, and as the version of Python in Buster is 3.7.3 and one of the dependencies for libpython3.9 is libc6 >= 2.29 which is higher than the version in Buster, trying to pull in libpeas from Bullseye will result in an upgrade of libc6 which will suck in a whole lot of other packages. As I see it, your choices are: 1. Upgrade to Bullseye. Bullseye is currently frozen and is likely to release soon, so this might be safe enough to do. I'm going to do this on one of my systems for a similar reason - I need Python > 3.7. You should read the release notes first though as there may be important changes (you should do this anyway). 2. Pull in libpeas from Bullseye anyway and accept all the upgraded packages. This will result in a partially upgraded system which is probably not a good idea, especially given that lib6 will be upgraded. 3. Build libpeas from source. I have no idea at all how involved this is and it may well be more work than it's worth, particularly given the dependencies. 4. Wait for Bullseye to release. HTH, Geoff._______________________________________________ orca-list mailing list orca-list gnome org https://mail.gnome.org/mailman/listinfo/orca-list Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html_______________________________________________ orca-list mailing list orca-list gnome org https://mail.gnome.org/mailman/listinfo/orca-list Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html_______________________________________________ orca-list mailing list orca-list gnome org https://mail.gnome.org/mailman/listinfo/orca-list Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html _______________________________________________ orca-list mailing list orca-list gnome org https://mail.gnome.org/mailman/listinfo/orca-list Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html_______________________________________________ orca-list mailing list orca-list gnome org https://mail.gnome.org/mailman/listinfo/orca-list Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html _______________________________________________ orca-list mailing list orca-list gnome org https://mail.gnome.org/mailman/listinfo/orca-list Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html_______________________________________________ orca-list mailing list orca-list gnome org https://mail.gnome.org/mailman/listinfo/orca-list Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Attachment:
OpenPGP_0x144312F3EB650A2D.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature