Re: Bug filing, and different application toolkits

[Bill Haneman <Bill Haneman Sun COM>]

Hi:

I'd like to make two quick comments.  Firstly, thanks a lot to Peter for 
providing the links to the bugzilla bug filing and tracking system (and 
issuezilla for StarOffice/OpenOffice issues); thanks also for the links 
to the bug HOWTO which is key to making the most of your bug reports.  I 
really would like to second what he said about the importance of these 
bug reports, and encourage everyone currently using or planning to use 
gnopernicus, gok, and the GNOME desktop to read his detailed post 
carefully as time permits.

The list discussion about general impressions, features, and requests 
for enhancement is very helpful to us.  But we agree that stability 
issues are fundamental, and when it comes to misbehaviors that are 
clearly bugs and errors, nothing beats a good bug report for finding and 
fixing these problems.

Your input, particularly in the form of bugzilla reports, is a key part 
of our efforts to improve and bring to completion our assistive 
technology and AT support work.  Of course the work is never really 
"complete", because neither users nor technology stand still, but in the 
free-software and open-source world particularly, your participation is 
a key part of the process.  Thanks in advance to everyone!

Secondly, and slightly off-topic: as Peter points out, our accessibility 
support is fundamentally different in that it's "built in" to the GNOME 
desktop and related accessible applications; KDE has committed to 
integrating support into their own toolkit in upcoming versions as well, 
in a sort of "retrofit".  This will bring the list of interoperable 
toolkits to a list including gtk+2, Java-Swing, and the internal 
toolkits used by Open/StarOffice and Mozilla.   In contrast to Windows, 
where the vast majority of applications are built on top of the same GUI 
libraries, the Linux and Unix world has always been more heterogeneous; 
the need to bridge between these different toolkits has been a 
fundamental consideration in the design of our accessibility architecture.

But not all applications are based on one of the toolkits which have 
adopted/implemented our architecture, as of this date.  Integrating 
accessibility support into a new toolkit is a major committment which 
individual application authors are rarely prepared to make, and there's 
no easy solution due to the richness and breadth required of 
comprehensive accessibility support.  In most cases, a port to GTK+2, or 
use of an alternative application which is already based on one of the 
AT-SPI-implementing toolkits, is more expedient.  As I believe Peter has 
suggested, one of our goals is to encourage the future GUI toolkits 
which will no doubt emerge, to incorporate the necessary accessibility 
support from the outset, so that the problem of "inaccessible toolkits" 
becomes a thing of the past.

The XMMS application which was mentioned in an earlier email doesn't use 
gtk+ or Qt, I believe it's a "pure X" application which means that it is 
not feasible to make it fully accessible without a rewrite or "port".

best regards,

Bill