Re: Text alternatives and GtkPixbuf [Was: GNOME Launches Campaign for Accessibility]
Bill Cox <[email protected]>
| Newsgroups | gmane.comp.gnome.accessibility.general,gmane.comp.gnome.accessibility.devel |
|---|---|
| Message-ID | <CAOLP8p6t2yocGoQWbbYRUkDJWd_4WhwGvZ01+3js5FdhVgoP2A@mail.gmail.com> |
Sorry, Benjamin. I'll try to keep it straight. Here's the problem with pixbuf that makes solving this issue hard without adding an accessible description directly to pixbuf. GTK does not build widgets for cells in lists, tables, and trees. Instead, you register a callback function that is responsible for drawing cells. This is a major improvement in efficiency vs building a widget for every cell, but the result is you don't have a widget allocated in memory where you can add a text description. The object used for drawing icons in lists, tables, and trees is GtkCellRendererPixbuf: http://www.gnu.org/software/guile-gnome/docs/gtk/html/GtkCellRendererPixbuf.html Programmers simply attach a pixbuf object to their model, and it's displayed automagically. This method is used in many GTK applications. The problem is there is nowhere on the pixbuf object to add a text description. This is why I can't contact the authors of the various programs which have icons in lists that don't talk and request that they add descriptions. They would have to do major changes to their code to get it to work. Specifically, they'd have to somehow draw images in their lists without using the GTK renderer designed for this purpose. Most GTK programmers would have no idea how to even start on such a task (including me!). Here's the pixbuf documentation: http://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-The-GdkPixbuf-Structure.html There are already 9 properties on pixbuf, so a text description would just raise this to 10. Also, the description of pixbuf is "The GdkPixbuf structure contains information that describes an image in memory. " Not having a text description seems like an oversight, one that is easily corrected. When I added one, I was able to fix three popular GTK applications so that users could hear how many stars a app was rated when installing software, and they could hear the status in Synaptic so they could know if a package was installed or not. In each case, adding a text description took only one extra line of code per icon. We tested these apps in Vinux for several months, without any problems. However, we decided that we did not want to maintain non-standard patches to GTK. The goal in Vinux is to help improve Linux accessibility, not maintain accessible custom versions of code that only run in Vinux. In short, adding the text description to pixbuf is very clearly the right solution. No other solution has been proposed for good reason. We'd have to change the cell renderer interface otherwise, and all the existing applications out there would need major changes. That level of disruption just isn't going to be accepted. This is a major accessibility problem in Gnome. The community offered a simple solution, and tested it. It's about as small a change to the code base as any patch can be, and would significantly improve the lives of Orca users. The fact that Gnome seems incapable of adopting fixes like this tells me that there is a major problem with the Gnome organization. A11y is clearly a high priority for Gnome at the highest levels, yet Gnome is not capable of fixing a critical a11y bug the code it manages, even when the community submits a simple tested patch. When a GTK programmer says on a community bug report "I don't think this is the right approach," managers need to understand that translates to "I don't want to do work my boss didn't specifically request, and a11y patches from the community aren't on the list." So, how do we get issues like this on the list? Bill