NVDA (NonVisual Desktop Access) es un lector de pantalla gratuito y de código abierto para Microsoft Windows.Está desarrollado por NV Access en colaboración con una comunidad global de contribuyentes.Para obtener más información sobre NVDA o descargar una copia, visite el sitio web principal de NV Access.

Tenga en cuenta: el proyecto NVDA tiene un Código de conducta para ciudadanos y contribuyentes. NV Access espera que todos los colaboradores y otros miembros de la comunidad lean y respeten las normas establecidas en este documento mientras participan o contribuyen a este proyecto.

Obtenga soporte

Tanto si es un principiante, un usuario avanzado, un desarrollador nuevo o de larga data, como si es una organización que desea saber más o contribuir a NVDA, puede obtener soporte a través de la documentación existente, así como de varios canales de comunicación dedicados para el lector de pantalla NVDA. He aquí un resumen de las fuentes de soporte más importantes.

Documentación

• Guía del usuario de NVDA
• Guía del desarrollador de NVDA
• Agregación de NVDAons Development Internals
• Manual de NVDA ControllerClient
• Se incluye más documentación en la Wiki de este repositorio y en la Wiki de la Comunidad

Canales de comunicación

• Lista de correo de usuarios de NVDA
• Lista de correo de desarrolladores de NVDA
• Lista de correo de Add-ons Mailing List
• Canal de mensajería instantánea para el soporte de NVDA
• Otras fuentes incluyendo grupos y perfiles en canales de medios sociales, sitios web de idiomas específicos y listas de correo, etc.

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

Otros enlaces clave del proyecto

• NVDA en GitHub
• Problemas de NVDA en GitHub: Informes de errores, peticiones de características, etc.
• Instancias de desarrollo de NVDA: Construcciones generadas automáticamente del proyecto en su estado actual de desarrollo
• Complementos de NVDA: Consigue complementos para mejorar NVDA
• Centro de coordinación y soporte de complementos de NVDA: todo sobre el entorno de complementos de NVDA
• Plantilla de complementos de NVDA: Un repositorio para generar la plantilla de Add-ons
• Traducir NVDA: Información sobre cómo traducir NVDA a otro idioma
• NVDA Controller Client (2010-02-19): API de NVDA para que aplicaciones externas puedan hablar directamente o braillear mensajes, etc.
• Contribuyendo a NVDA: Directrices para contribuir al código fuente de NVDA
• Lista de correo electrónico de commits de NVDA: Notificaciones para todos los commits del repositorio Git
• Archivos de correo electrónico antiguos: contienen discusiones sobre el desarrollo de NVDA

Obtener el código fuente

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

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

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

La opción --recursive es necesaria para recuperar varios submódulos Git que utilizamos.

Dependencias

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

Dependencias instaladas

Las siguientes dependencias deben estar instaladas en su sistema:

• Python, versión 3.8, 32 bits
  • Use la última versión menor si es posible.
• Microsoft Visual Studio 2019 Community, versión 16.3 o posterior:
  • Descargue desde https://visualstudio.microsoft.com/vs/
  • Cuando instale Visual Studio, deberá habilitar lo siguiente:
    • En la pestaña Cargas de trabajo
      • del grupo Windows:
        • Desarrollo de escritorio con C++
      • Después, en la sección Detalles de la instalación, en Escritorio para C++, Agrupación opcional, asegúrese de seleccionar lo siguiente:
        • MSVC v142 – VS 2019 C++ x64/x86 build tools
        • Windows 10 SDK (10.0.19041.0)
        • C++ ATL for v142 build tools (x86 & x64)
        • C++ Clang tools for Windows
    • En la pestaña Componentes individuales, asegúrese de que los siguientes elementos están seleccionados:
      • MSVC v142 – VS 2019 C++ ARM64 build tools
      • C++ ATL para v142 build tools (ARM64)

Submódulos Git

Algunas de las dependencias están contenidas en submódulos Git.Si no has pasado la opción --recursive a git clone, tendrás que ejecutar git submodule update --init.Siempre que cambie el commit de un submódulo requerido (por ejemplo, después de un git pull), necesitarás ejecutar git submodule update.Si no estás seguro, ejecuta git submodule update después de cada git pull, merge o checkout.

Para referencia, las siguientes dependencias en tiempo de ejecución están incluidas en los submódulos Git:

• eSpeak NG, versión 1.51-dev commit 53915bf0a
• Sonic, commit 4f8c1d11
• IAccessible2, commit cbc1f29631780
• liblouis, versión 3.17.0
• Unicode Common Locale Data Repository (CLDR), versión 38.1
• Imágenes y sonidos NVDA
• Interfaz de accesibilidad de Adobe Acrobat, versión XI
• MinHook, versión etiquetada 1.2.2
• brlapi Python bindings, versión 0.8 o posterior, distribuido con BRLTTY para Windows, versión 6.1
• lilli.dll, versión 2.1.0.0
• Interfaz de Python con el controlador/chip FTDI
• Puente de acceso a Java de 32 bits, desde Zulu Community OpenJDK build 13.0.1+10Zulu (13.28.11)

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

• txt2tags, versión 2.5
• Nulsoft Install System, versión 2.51
• NSIS UAC plug-in, versión 0.2.4, ansi
• xgettext y msgfmt de GNU gettext
• Boost Optional (stand-alone header), del commit 3922965

Las siguientes dependencias no son necesarias para la mayoría de la gente, y no se incluyen en los submódulos Git:

• Generar documentación para desarrolladores para nvdaHelper: Instalador de Doxygen para Windows, versión 1.8.15:

• Cuando utilice Visual Studio Code como su entorno de desarrollo integrado de preferencia, puede hacer uso de nuestra configuración de espacio de trabajo prepoblado para Visual Studio Code.Aunque este proyecto VSCode no está incluido como submódulo en el repositorio de NVDA, puedes comprobar fácilmente la configuración del espacio de trabajo en tu repositorio ejecutando lo siguiente desde la raíz del repositorio.

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

Dependencias de Python

NVDA y su sistema de construcción también dependen de una extensa lista de paquetes de Python. Todos ellos están listados con sus versiones específicas en un archivo requirements.txt en la raíz de este repositorio. Sin embargo, el sistema de construcció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 de todo el sistema.

Preparando el árbol de fuentes

Antes de que puedas ejecutar el código fuente de NVDA, debes preparar el árbol de fuentes.Lo haces abriendo un símbolo del sistema, cambiando a la raíz de la distribución de fuentes de NVDA y escribiendo:

scons source

Debes hacer esto de nuevo cada vez que la versión de comtypes cambie o se añadan o cambien archivos de lenguaje.Tenga en cuenta que si desea acceder a la documentación del usuario desde el menú de ayuda mientras se ejecuta la versión de origen, también tendrá que añadir user_docs a la línea de comandos de la siguiente manera:

scons source user_docs

Mientras simplemente se prueban o confirman los cambios, puede ser más rápido por lo general sólo haciendo scons source ya que la documentación del usuario cambiará cada vez que el número de revisión cambie.

Compilar NVDAHelper con opciones de depuración

Entre otras cosas, preparar el árbol de fuentes construye las bibliotecas de NVDAHelper.Si se intenta depurar nvdaHelper, se pueden controlar varias opciones de depuración construyendo con las variables de línea de comandos nvdaHelperDebugFlags y nvdaHelperLogLevel.

La variable nvdaHelperLogLevel especifica el nivel de registro (0-59) que se desea ver, más bajo es más verboso. El valor por defecto es 15.

La variable nvdaHelperDebugFlags toma una o más de las siguientes banderas:

• debugCRT: las bibliotecas se enlazarán contra el tiempo de ejecución de C de depuración y se habilitarán las aserciones. (Por defecto, se utiliza el CRT normal y las aserciones están deshabilitadas.)
• RTC: se habilitarán las comprobaciones en tiempo de ejecución (corrupción de pila, variables no inicializadas, etc.). (El valor por defecto es sin comprobaciones en tiempo de ejecución.)
• analyze: ejecuta el análisis de código MSVC en todo el código de nvdaHelper, holting en cualquier advertencia. (por defecto no hay análisis).

Las palabras clave especiales none y all también pueden usarse en lugar de las banderas individuales.

A continuación se muestra un ejemplo que habilita la depuración de CRT y las comprobaciones de runtype

scons source nvdaHelperDebugFlags=debugCRT,RTC

Los archivos pdb de símbolos siempre se producen al construir, independientemente de las banderas de depuración.Sin embargo, no se incluyen en la distribución NVDA.En su lugar, scons symbolsArchive los empaquetará como un archivo separado.

Por defecto, las construcciones tampoco utilizan ninguna optimización del compilador.Por favor, vea el argumento de la palabra clave release para saber qué optimizaciones del compilador habilitará.

Ejecutar el código fuente

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

Para ver la ayuda sobre los argumentos que aceptará NVDA, utilice la opción -h o --help.Estos argumentos también están documentados en la guía del usuario.

Construir NVDA

Una construcción binaria de NVDA puede ejecutarse en un sistema sin Python y todas las demás dependencias de NVDA instaladas (como hacemos para las instantáneas y las versiones).

Los archivos binarios y los paquetes pueden crearse utilizando scons desde la raíz de la distribución de fuentes de NVDA. Para construir cualquiera de los siguientes, abra un símbolo del sistema y cambie a este directorio.

Para hacer una construcción binaria no archivada (equivalente a un archivo portátil extraído), escriba:

scons dist

La construcción se creará en el directorio dist.

Construir el instalador

Para crear un archivo lanzador (un ejecutable que permita la instalación o la generación de dist portátil), escriba:

scons launcher

El archivo se colocará en el directorio de salida.

Construir la documentación del desarrollador

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

scons developerGuide

La guía del desarrollador se colocará en la carpeta devDocs del directorio de salida.

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

scons devDocs

La documentación se colocará en la carpeta NVDA del directorio de salida.

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

scons devDocs_nvdaHelper

La documentación se colocará en la carpeta devDocs\nvdaHelper del directorio de salida.

Generar archivo de símbolos de depuración

Para generar un archivo de símbolos de depuración para los distintos binarios dll/exe, escriba:

scons symbolsArchive

El archivo se colocará en el directorio de salida.

Generar plantilla de traducción

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

scons pot

Personalizar la compilación

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

• versión: La versión de esta compilación.
• release: Si se trata de una versión de lanzamiento.
  • Esto permite varias optimizaciones del compilador de C++ como /O2 y la optimización de todo el programa.
  • También indica a Python que genere código de bytes optimizado.
• publisher: El editor de esta compilación.
• certFile: El archivo de certificado con el que firmar los ejecutables. El certificado debe estar en formato pfx y contener la clave privada.
• certPassword: La contraseña para la clave privada en el certificado de firma. Si se omite, no se asumirá ninguna contraseña.
• certTimestampServer: La URL del servidor de sellado de tiempo que se utilizará para sellar el tiempo de las firmas authenticode. Si se omite, las firmas no serán timestampadas.
• outputDir: El directorio donde se colocarán los archivos finales construidos y demás.
• targetArchitectures: Las arquitecturas de destino que NVDA debe soportar. Los valores posibles son todos, x86 y x86_64. Por lo general, esto debería dejarse como el valor predeterminado.

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

scons launcher version=test1

Para más ver el archivo sconstruct.

Ejecución de pruebas automatizadas

Si hace un cambio en el código de NVDA, debería ejecutar las pruebas automatizadas de NVDA.Estas pruebas ayudan a asegurar que los cambios en el código no rompen involuntariamente la funcionalidad que estaba funcionando previamente.

Para ejecutar las pruebas (pruebas unitarias, comprobaciones de cadenas traducibles), primero cambia el directorio a la raíz de la distribución de fuentes de NVDA como se indica arriba.Luego, ejecuta:

scons tests

Pruebas unitarias

Para ejecutar sólo pruebas unitarias específicas, especifícalas usando la variable unitTests en la línea de comandos.Las pruebas deben proporcionarse como una lista separada por comas.Cada prueba debe especificarse como un módulo, clase o método de Python relativo al directorio tests\unit.Por ejemplo, para ejecutar sólo los métodos de las clases TestMove y TestSelection del archivo tests\unit\test_cursorManager.py, ejecute este comando:

scons tests unitTests=test_cursorManager.TestMove,test_cursorManager.TestSelection

Comprobaciones de cadenas traducibles

Para ejecutar sólo las comprobaciones de cadenas traducibles (que comprueban que todas las cadenas traducibles tienen comentarios del traductor), ejecute:

scons checkPot

Linting your changes

Para asegurar que tus cambios cumplen con el estilo de codificación de NVDA puedes ejecutar el linter Flake8 localmente.Algunos desarrolladores han encontrado ciertos mensajes de error de linting engañosos, estos se aclaran en tests/lint/readme.md.runlint.bat utilizará Flake8 para inspeccionar sólo las diferencias entre tu directorio de trabajo y la rama base especificada.Si creas una Pull Request, la rama base que utilizas aquí debe ser la misma que el objetivo que utilizarías para una Pull Request. En la mayoría de los casos será origin/master.

runlint origin/master

Para ser advertido de los errores de linting más rápido, es posible que desee integrar Flake8 otras herramientas de desarrollo que está utilizando.Para más detalles, consulte tests/lint/readme.md

Pruebas unitarias

Las pruebas unitarias se pueden ejecutar con el script rununittests.bat.Internamente este script utiliza el marco de pruebas Nose Python para ejecutar las pruebas.Cualquier argumento dado a rununittests.Por favor, consulte la propia documentación de Nose sobre cómo filtrar las pruebas, etc.

Pruebas del sistema

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

Contribuir a NVDA

Si quieres contribuir con código o documentación a NVDA, puedes leer más información en nuestra guía de contribución.