NVDA (Non Visual Desktop Access) es un lector de pantalla gratuito y de código abierto para Microsoft Windows.
Es desarrollado por NV Access en colaboración con una comunidad global de usuarios.
Para aprender más sobre NVDA o descargar una copia, visita el sitio web principal de NV Access.

Nota importante: el proyecto NVDA tiene un código de conducta del ciudadano y el colaborador. NV Access espera que todos los colaboradores y otros miembros de la comunidad lean y cumplan las reglas escritas en este documento al participar y colaborar en este proyecto.

Obtención de soporte

Ya seas un principiante, un usuario avanzado, un desarrollador novato o con experiencia, o representas a una organización dispuesta a saber más o colaborar con NVDA: puedes obtener soporte de la documentación incluida, así como de canales de comunicación dedicados al lector de pantalla NVDA. Aquí hay una descripción general de las fuentes de soporte más importantes.

Documentación

Canales de comunicación

También puedes obtener soporte directo de NV Access. Consulta el sitio web de NV Access para más detalles.

Otros enlaces clave del proyecto

Obtención del código fuente

El proyecto NVDA usa el sistema de control de versiones Git para su código fuente y documentación.

El repositorio git de NVDA está ubicado en https://github.com/nvaccess/nvda.git. Puedes clonarlo con el siguiente comando, que situará los archivos en un directorio llamado nvda:

git clone --recursive https://github.com/nvaccess/nvda.git

La opción --recursive se usa para recuperar varios submódulos Git necesarios.

Dependencias

El código fuente de NVDA depende de varios paquetes para ejecutarse correctamente.

Dependencias instaladas

Necesitas instalar las siguientes dependencias en tu sistema:

  • Python, versión 3.7 de 32 bits
    • Utiliza la última revisión menor si es posible.
  • Microsoft Visual Studio 2019:
    • Para replicar el entorno de compilación en producción, usa la versión de Visual Studio utilizada por AppVeyor.
    • Descarga desde https://visualstudio.microsoft.com/downloads/
      • Si no usas el propio entorno de desarrollo de Visual Studio, puedes descargar las herramientas de compilación bajo el encabezado expandible Herramientas de Visual Studio 2019
      • Si te propones usar el entorno de desarrollo Visual Studio (no es necesario para el desarrollo de NVDA), puedes descargar la versión Community bajo el encabezado expandible Visual Studio 2019
    • Al instalar Visual Studio, necesitas activar lo siguiente:
      • En la lista de la pestaña cargas de trabajo
        • En la agrupación Windows:
          • Desarrollo para escritorio con C++
        • A continuación, en el árbol detalles de la instalación, bajo C++ para escritorio, en el grupo opcional, asegúrate de que se ha seleccionado lo siguiente:
          • Herramientas de compilación MSVC v142 – VS 2019 C++ x64/x86
          • Windows 10 SDK (10.0.19041.0)
          • ATL de C++ para las herramientas de compilación V142 (X86 y X64)
          • Herramientas Clang de C++ para Windows
      • En la pestaña componentes individuales, asegúrate de que los siguientes están seleccionados:
        • Herramientas de compilación MSVC v142 – VS 2019 C++ ARM64
        • ATL de C++ para las herramientas de compilación V142 (ARM64)

Submódulos Git

Algunas de las dependencias van dentro de submódulos Git.
Si no pasaste la opción –recursive a git clone, tendrás que ejecutar git submodule update –init.
Cada vez que cambie el commit relacionado con un submódulo necesario (por ejemplo después de git pull), deberás ejecutar git submodule update.
Si no estás seguro, ejecuta git submodule update después de hacer pull, merge o checkout.

Para referencia, las siguientes dependencias de tiempo de ejecución se incluyen como submódulos Git:

Además, las siguientes dependencias de tiempo de compilación también se incluyen en el submódulo Git miscDeps:

Estas dependencias no vienen incluidas en submódulos Git, y casi nadie las necesita:
* Para generar la documentación para nvdaHelper: Doxygen Windows installer, versión 1.8.15:
* Si utilizas Visual Studio Code como tu entorno de desarrollo preferido, puedes emplear la configuración de espacio de trabajo preconcebida para Visual Studio Code.
Aunque este proyecto de VS Code no se incluye como un submódulo en el repositorio de NVDA, se puede situar fácilmente la configuración de espacio de trabajo en el repositorio ejecutando lo siguiente desde la raíz del repositorio.

```git clone https://github.com/nvaccess/vscode-nvda.git .vscode```

Dependencias Python

NVDA y su sistema de compilación también dependen de una extensa lista de paquetes Python. Se enumeran todos ellos con sus versiones específicas en el archivo requirements.txt en la raíz de este repositorio. No obstante, el sistema de compilación se encarga de obtenerlos por sí mismo cuando los necesita. Estos paquetes se instalarán en un entorno virtual aislado de Python dentro de este repositorio, y no afectarán al conjunto de paquetes del sistema.

Preparación del código fuente

Antes de que puedas ejecutar NVDA desde el código fuente, debes prepararlo.
Esto se hace abriendo un símbolo del sistema, cambiando a la raíz del repositorio con el código fuente y escribiendo:

scons source

Esto debes hacerlo cada vez que cambie la versión de comtypes o se añadan o modifiquen archivos de idioma.
Si quieres acceder a la documentación del usuario desde el menú ayuda de NVDA mientras lo ejecutas desde el código fuente, tendrás que añadir en la consola user_docs. Por ejemplo:

scons source user_docs

Mientras hagas pruebas simples o envíes cambios, será más rápido ejecutar scons source, ya que la documentación de usuario cambiará cada vez que se modifique el número de revisión.

Compilación de NVDAHelper con opciones de depuración

Entre otras cosas, la preparación del código fuente construye las bibliotecas de NVDAHelper.
Si tu intención es depurar nvdaHelper, puedes controlar diversas opciones de depuración compilando con las variables nvdaHelperDebugFlags y nvdaHelperLogLevel en la consola.

La variable nvdaHelperLogLevel especifica el nivel de registro (0-59) que desees ver, cuanto más bajo más expresivo. Por defecto, su valor es 15.

La variable nvdaHelperDebugFlags acepta uno o varios de los siguientes valores:

  • debugCRT: las bibliotecas se enlazarán con el tiempo de ejecución de C para depuración y se habilitarán las aserciones. (por defecto se deshabilitan las aserciones y se usa el crt normal).
  • RTC: se activarán las comprobaciones en tiempo de ejecución (corrupción de pila, variables sin inicializar, etc.). (por defecto no se hacen pruebas en tiempo de ejecución).
  • analyze: ejecuta el análisis de código de MSVC en todo el código de NVDAHelper, mostrando cada advertencia. (por defecto no hay análisis)

Las palabras clave none y all pueden usarse en lugar de cada valor por separado.

A continuación se muestra un ejemplo que activa las comprobaciones en tiempo de ejecución y la depuración con crt 

scons source nvdaHelperDebugFlags=debugCRT,RTC

Independientemente de las variables de depuración, siempre se generan archivos de símbolos pdb al construir.
Sin embargo, no se incluyen en la distribución de NVDA.
En vez de eso, scons symbolsArchive los empaqueta en un archivo separado.

Por defecto, la compilación se hace sin argumentos de optimización.
Mira el argumento release más abajo para saber qué optimizaciones se activan al usarlo.

Ejecución del código fuente

Es posible ejecutar NVDA desde el código fuente directamente sin tener que construir el paquete binario completo ni el instalador.
Para iniciar NVDA desde el código fuente, utilizando cmd.exe, ejecuta runnvda.bat en la raíz del repositorio.

Para ver una ayuda sobre los argumentos que acepta NVDA, usa las opciones --help o -h.
Estos argumentos también están documentados en la guía de usuario.

Construcción de NVDA

Una versión binaria de NVDA puede ejecutarse en un sistema sin Python y todas las demás dependencias instaladas (tal y como hace NV Access con las liberaciones oficiales y las versiones de desarrollo).

Se pueden construir archivos binarios y paquetes usando scons desde la raíz de la distribución del código fuente de NVDA. Para construir cualquiera de ellos, abre un símbolo del sistema y navega a este directorio.

Para hacer una versión binaria no archivada (equivalente a un portable extraído) escribe:

scons dist

La versión compilada se creará en el directorio dist.

Construcción del instalador

Para crear un archivo de lanzador (un ejecutable que permite instalar NVDA o generar un portable) escribe:

scons launcher

El archivo se ubicará en el directorio output.

Construcción de la documentación para desarrolladores

Para generar la guía del desarrollador de NVDA, escribe:

scons developerGuide

La guía del desarrollador aparecerá en la carpeta devDocs dentro del directorio output.

Para generar la documentación del código fuente basada en HTML, escribe:

scons devDocs

La documentación aparecerá en la carpeta NVDA dentro del directorio output.

Para generar documentación para desarrolladores de nvdaHelper (no incluida en devDocs):

scons devDocs_nvdaHelper

La documentación aparecerá en la carpeta devDocs\nvdaHelper dentro del directorio output.

Generación del archivo de símbolos de depuración

Para generar un archivo con símbolos de depuración de los diversos exes y dlls, escribe:

scons symbolsArchive

El archivo se ubicará en el directorio output.

Generación de la plantilla de traducción

Para generar una plantilla de traducción gettext (para traductores), escribe:

scons pot

Personalización de la compilación

Opcionalmente, la compilación puede personalizarse proporcionando variables en la línea de órdenes:

  • version: la versión de esta compilación.
  • release: indica si esta es una liberación oficial.
    • Esto activa algunas optimizaciones del compilador de C++ como el argumento /O2 o la optimización del programa completo.
    • También indica a Python que genere bytecode optimizado.
  • publisher: el autor de esta compilación.
  • certFile: el archivo con el certificado usado para firmar ejecutables. Debe estar en formato pfx y contener la clave privada dentro.
  • certPassword: la contraseña de la clave privada del certificado. Si se omite, se asume que no hay contraseña.
  • certTimestampServer: la URL del servidor de sellado de tiempo a utilizar para la marca de tiempo authenticode en las firmas. Si se omite, la firma no se sellará.
  • outputDir: el directorio donde se ubicarán los archivos construidos.
  • targetArchitectures: las arquitecturas que debería soportar NVDA. Sus posibles valores son all, x86 y x86_64. Generalmente debería dejarse como está.

Por ejemplo, para construir un lanzador con una versión específica, podrías escribir:

scons launcher version=test1

Para ver más variables, consulta el archivo sconstruct.

Ejecución de pruebas automatizadas

Si haces cambios al código de NVDA, deberías ejecutar sus pruebas automatizadas.
Estas pruebas ayudan a asegurar que los cambios en el código no rompen de forma involuntaria alguna funcionalidad que previamente estaba operativa.

Para realizar las pruebas (pruebas unitarias, comprobación de cadenas traducibles), navega al directorio raíz del repositorio como se ha indicado más arriba.
A continuación, ejecuta:

scons tests

Pruebas unitarias

Para ejecutar solamente pruebas unitarias específicas, indícalas en la variable unitTests en la línea de órdenes.
Las pruebas deberían proporcionarse en una lista separadas por comas.
Cada prueba debería especificarse como un módulo, clase o método relativo al directorio tests\unit.
Por ejemplo, para ejecutar sólo los métodos en las clases TestMove y TestSelection del archivo tests\unit\test_cursorManager.py, escribe esta orden:

scons tests unitTests=test_cursorManager.TestMove,test_cursorManager.TestSelection

Comprobación de cadenas traducibles

Para ejecutar solamente las comprobaciones de cadenas traducibles (que comprueban que todas las cadenas tienen comentarios para traductores), escribe:

scons checkPot

Comprobación del estilo de tus cambios

Para garantizar que tus cambios cumplen con el estilo de codificación de NVDA, puedes ejecutar el comprobador Flake8 localmente.
Algunos desarrolladores han encontrado ciertos mensajes de error de comprobación de estilo sin sentido, estos se aclaran en tests/lint/readme.md.
runlint.bat usará Flake8 para inspeccionar únicamente las diferencias entre tu directorio de trabajo y la rama base especificada.
Si creas una solicitud de cambios, la rama base para ese caso debería ser la misma que el destino que usarías para la solicitud de cambios. En la mayoría de los casos será origin/master.

runlint origin/master

Para recibir avisos más deprisa sobre errores de estilo, podrías querer integrar Flake8 con otras herramientas de desarrollo que utilices.
Para más detalles, consulta tests/lint/readme.md

Pruebas unitarias

Se pueden ejecutar las pruebas unitarias con el script rununittests.bat.
Internamente, este script usa el framework de pruebas Python Nose para ejecutar las pruebas.
Cualquier argumento dado a rununittests.bat se reenvía a Nose.
Consulta la propia documentación de Nose para saber cómo filtrar pruebas, etc.

Pruebas del sistema

Las pruebas de sistema se pueden ejecutar con el script runsystemtests.bat.
Internamente, este script usa el framework de pruebas Robot para ejecutar las pruebas.
Cualquier argumento dado a runsystemtests.bat se reenvía a Robot.
Para más detalles (incluyendo filtrado y exclusión de pruebas), consulta tests/system/readme.md.

Colaboración con NVDA

Si deseas colaborar con NVDA aportando código o documentación, puedes leer más sobre ello en la guía de colaboración.