From kde-accessibility Wed Mar 29 13:17:23 2006 From: Olaf Jan Schmidt Date: Wed, 29 Mar 2006 13:17:23 +0000 To: kde-accessibility Subject: Re: [Kde-accessibility] Message-Id: <200603291517.24770.ojschmidt () kde ! org> X-MARC-Message: https://marc.info/?l=kde-accessibility&m=114363862115658 Hi! I agree with Richard and Bill that we need more people working on AT-SPI. One of the reasons KDE developers did not contribute to AT-SPI so far is that we have very few people knowing CORBA, which makes contributing to AT-SPI very difficult for us - and seemingly for most IBM and Sun developers (apart from Bill and Peter) alike. I know people who would love to use AT-SPI for KDE4-based assistive technologies, but currently there are no Qt/KDE bindings that allow us to do so. We have several options to create these bindings: 1. Write code that bridges the gobject-based AT-SPI bindings to QObject-based bindings, which probably involves solving the problem of having two event loops. This approach is a lot of work, and it is no fun, which means that volunteers are unlikely to work on it. 2. Write an IDL compiler that creates both gobject-based and QObject-based bindings for AT-SPI. This approach is more work than option 1 or 3, but it fits our agreed long term strategy. I don't know whether there are KDE developers who want to work on this, and it seems none of the GNOME developers are willing to contribute in the forseeable future. 3. Implement the AT-SPI API on top of DBUS, in addition to the CORBA version. Qt4/KDE4 applications will be able to talk to both versions, so the existing assistive technologies will not suffer. This is more work than option 1, but we could start with a subset of AT-SPI to quickly have workable results. Once the bindings are tested and stable, we can write the necessary bridges to make sure that application using the glib-based bindings can also talk to the KDE4-based assistive technologies (using option 1, option 2 or an external CORBA-DBUS bridge). It seems most likely to me that people would be willing to work on this. Whenever I tried to convince KDE people to work on option 2 or 3, Bill objected saying that we should not work on a DBUS-version of AT-SPI at the current point of time. This gave me the impression that Bill favours option 1, and this is why I asked when the number of dependencies on the existing AT-SPI implementation will be reduced. I fully understand that Bill does not want to spend time on reducing dependencies if we are planning to move to DBUS anyway at some point in the future. What I don't agree with is discouraging KDE people (who would not be able contribute to a CORBA-based version anyway) to work on the DBUS port of AT-SPI, or calling this "NIH". I know that Bill will be away for two months soon. Harald (who writes the AT-SPI bridges for Qt) will also be on holiday for some weeks. When both of you are back, then we will hopefully have DBUS support in the KDE4 development versions, which will put us in the position to start implementing option 2 or 3. [ Richard Schwerdtfeger ] > Given the enormous task of managing the ATK/AT-SPI code base I believe Bill > has done an incredible job. I fully agree. [...] > Bill is an overwhelmed one-man band and we need to put more resources on to > help rather than setting off a grenade. Yes, we need more people contributing, and to achieve this, we must make sure that AT-SPI is as easy to use as possible. For KDE developers, means DBUS. Otherwise AT-SPI contributitions will stay limited to a very small number of full-time paid experts. Please remember that accessibility is not only about blind people or severely impaired users. There is a huge number of needs - both for people with disability and for people without disabilities. Some of these needs can easily be met with small, modular tools. And some of these smaller tools can benefit a lot from AT-SPI if using it is not too complicated. A good example for this is GOK. GOK is a very sophisticated assistive technology that works really great for people with severe mobility impairments. But at the same time, there are people with other disabilities that need an easier solution that can be used with the standard mouse. If we only look at the big assistive technologies, then we forget the need to make usage of AT-SPI simple enough for the authors of smaller tools. [Bill Haneman] > It also seems to be to be putting the "cart before the horse" to insist on a > gnome-library-free accessibility stack before KDE application developers are > willing to start testing their own applications' accessibility, or to start > writing some AT-SPI based technologies. I fully agree with you that it would be foolish not to test the accessibiilty of KDE applications because the tools are not native. At the same time, please keep in mind that most KDE developers are volunteers. Accessibility testing is not exactly fun, and this is why I want to make it as easy for them as possble. Every additional library and application that needs to be installed might prevent some developers from doing these accessibility tests - not because of bad intention or because of "NIH". It would simply mean extra work to install the additional tools, and people would say "I'll do it later" and forget about it. > For instance, I have taken another look at the libbonobo/bonobo > dependency issues in the atk-bridge today (presumably this is one of the > areas where KDE would most like to reduce the number of GNOME libraries > linked in). The dependencies do seem of a manageable size and sort, but > on the other hand, libbonobo is not huge (about 1 MB), and you'd have to > replace it with something (e.g. new code) if you removed it. It's the > sort of thing that a patch could be reasonably created for. > > Frankly I think a patch to remove the bonobo-activation dependency > (replacing it with DBUS activation, presumably) would make a lot more > sense at this time, in terms of cost/benefit. That would be a nice > opportunity for someone to fix the 'activation of remotely-displayed > apps' problem as well, and to allow one AT-SPI registry per display - > presuming DBUS can currently support that use case (i.e. per-display, > user-agnostic activation and query). Thanks for spending the time to come up with a specific suggestion where people might be able to contribute. Olaf -- Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards accessibility networker, Protestant theology student and webmaster of http://accessibility.kde.org/ and http://www.amen-online.de/ _______________________________________________ kde-accessibility mailing list kde-accessibility@kde.org https://mail.kde.org/mailman/listinfo/kde-accessibility