La semana pasada estuve trabajando en combinar los repositorios de atk y at-spi2-atk dentro del repo de at-spi2-core. Pequeño recordatorio de qué hace cada uno:
-
at-spi2-core: Tiene las definiciones en XML de las interfases DBus para accesibilidad — lo que le permite a un control gráfico arbitrario identificarse con el rol de un Botón, o lo que le permite a un control de texto pasarle su contenido textual a un lector de pantalla. También contiene el demonio de registro de accesibilidad, que es quien multiplexa las aplicaciones hacia los lectores de pantalla u otras tecnologías de accesibilidad. También tiene la bibliotecalibatspi, que es un binding escrito a mano para las interfases DBus, y que se usa por... -
at-spi2-atk: Traduce el API de ATK a llamadas delibatspi, para hacer que ATK platique vía DBus con el demonio de registro de accesibilidad. Toda esta capa intermedia existe porque... -
atk: es sólo un montón de interfases de GObject para que programas arbitrarios se puedan exponer como accesibles por lectores de pantalla. GTK3, LibreOffice y Mozilla lo usan. Esto es a diferencia de GTK4 y Qt5, que platican vía DBus directamente con el stack de accesibilidad y así se evitan dos capas intermedias.
¿Por qué combinar los repositorios?
Las interfases de DBus en at-spi2-core, la forma en que funciona el demonio de registro de accesibilidad, las interfases de atk y su pegamento en at-spi2-atk vía libatspi... todo eso está "cerradamente acoplado" (tightly coupled). No puedes hacer un cambio en el API de libatspi sin cambiar at-spi2-atk, y un cambio en las interfases de DBus debería verse reflejado en todo el código; pero mantener todo esto en sincronía es más difícil de lo necesario si se tienen los repositorios separados.
Aun estoy en proceso de aprender cómo funciona el código de accesibilidad, y mi estrategia para aprender un código nuevo, además de leerlo y tomar notas, es hacer un poco de refactorización experimental.
Sin embargo, cuando empecé a refactorizar un pedacito de at-spi2-core, resultó que las pruebas que me permitirían ver si mi trabajo era correcto estaban en otro repositorio. Esto es código muy viejo, de cuando era sumamente engorroso tener pruebas unitarias en C, y requeriría mucho más refactorización para llevarlo a un estado en que se puedan tener pruebas unitarias. Entonces, necesito pruebas de principio a fin...
... y es at-spi2-atk en donde están las pruebas de principio a fin para toda la maquinaria intermedia de accesibilidad. No están en at-spi2-core, que es el módulo en el que yo estaba trabajando. At-spi2-atk es donde viven este tipo de pruebas:
- Crear una aplicación accesible simulada ("mi_applicación").
- Crear una tecnología de accesibilidad simulada ("mi_lector_de_pantalla").
- Ver si lo que se transfiere de la primera a la segunda tiene sentido, probando así la maquinaria intermedia de accesibilidad.
Al combinar estos tres respositorios, y añadiendo un reporte de cobertura de código para las pruebas, podemos añadir una prueba, modificar algo de código, mirar el reporte de cobertura, y ver si la prueba de verdad hizo que se ejecutara el código que modificamos.
Cambios para las distribuciones
Por favor mira el anuncio en discourse.gnome.org.
¡Pero ese reporte de cobertura de código no es accesible!
Sí, es bastante horrendo. La herramienta genhtml de lcov genera un
<pre> gigantesco, y pone cosas como la cuenta de veces que se
ejecutó cada línea como un <span>. Ejemplo del HTML producido por
lcov.
(El reporte de cobertura de librsvg no es mucho mejor; la salida HTML
de grcov es un montón de <div> con colores y ya. Ejemplo del HTML
producido por grcov.)
¿Alguien conoce una herramienta de cobertura de código que genere reportes accesibles?