NVDA (NonVisual Desktop Access) est un lecteur d’écran gratuit et open source pour Microsoft Windows.Il est développé par NV Access en collaboration avec une communauté mondiale de contributeurs.Pour en savoir plus sur NVDA ou télécharger une copie, visitez le site principal de NV Access.

Veuillez noter : le projet NVDA a un code de conduite pour les citoyens et les contributeurs. NV Access attend de tous les contributeurs et autres membres de la communauté qu’ils lisent et respectent les règles énoncées dans ce document lorsqu’ils participent ou contribuent à ce projet.

Obtenir de l’aide

Que vous soyez un débutant, un utilisateur avancé, un nouveau développeur ou un développeur de longue date, ou si vous êtes une organisation désireuse d’en savoir plus ou de contribuer à NVDA, vous pouvez obtenir de l’aide grâce à la documentation en place ainsi qu’à plusieurs canaux de communication dédiés au lecteur d’écran NVDA. Voici un aperçu des sources de support les plus importantes.

Documentation

• Guide de l’utilisateur de NVDA
• Guide du développeur de NVDA
• Ajouts de NVDA-ons Development Internals
• NVDA ControllerClient manual
• De la documentation supplémentaire est incluse dans le Wiki de ce référentiel et dans le Wiki de la Communauté

Canaux de communication

• Liste de diffusion des utilisateurs de NVDA
• Liste de diffusion des développeurs de NVDA
• NVDA Add-.ons Mailing List
• Canal de messagerie instantanée pour le support NVDA
• Autres sources, y compris les groupes et les profils sur les canaux de médias sociaux, sites web et listes de diffusion spécifiques à une langue, etc.

Vous pouvez également obtenir un soutien direct de NV Access. Voir le site web de NV Access pour plus de détails.

Autres liens clés du projet

• NVDA sur GitHub
• Les problèmes de NVDA sur GitHub : Rapports de bogues, demandes de fonctionnalités, etc.
• Les instantanés de développement de NVDA : Constructions générées automatiquement du projet dans son état actuel de développement
• Les add-ons NVDA : Obtenez des add-ons pour améliorer NVDA
• Centre de coordination et de support des add-ons NVDA : tout sur l’environnement des add-ons de NVDA
• Modèle d’add-ons NVDA : Un référentiel pour générer le modèle d’add-ons
• Traduire NVDA : informations sur la façon de traduire NVDA dans une autre langue
• Client contrôleur NVDA (2010-02-19) : API NVDA pour les applications externes afin de parler directement ou de brailler les messages, etc.
• Contribuer à NVDA : Directives pour contribuer au code source de NVDA
• Liste de courriel des commits NVDA : Notifications pour tous les commits du dépôt Git
• Anciennes archives de courriels : contiennent des discussions sur le développement de NVDA

Obtenir le code source

Le projet NVDA utilise le système de contrôle de version Git pour son code source et sa documentation.

Le dépôt Git de NVDA est situé à https://github.com/nvaccess/nvda.git. Vous pouvez le cloner avec la commande suivante, qui placera les fichiers dans un répertoire nommé nvda:

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

L’option --recursive est nécessaire pour récupérer divers sous-modules Git que nous utilisons.

Dépendances

La source NVDA dépend de plusieurs autres paquets pour fonctionner correctement.

Dépendances installées

Les dépendances suivantes doivent être installées sur votre système :

• Python, version 3.8, 32 bits
  • Utiliser la dernière version mineure si possible.
• Microsoft Visual Studio 2019 Community, version 16.3 ou ultérieure :
  • Télécharger à partir de https://visualstudio.microsoft.com/vs/
  • Lors de l’installation de Visual Studio, vous devez activer les éléments suivants :
    • Sur l’onglet Charges de travail
      • dans le groupe Windows :
        • Développement de bureau avec C++
      • Puis dans la section Détails de l’installation, sous Bureau pour C++, groupement optionnel, assurez-vous que les éléments suivants sont sélectionnés :
        • 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
    • Sur l’onglet Individual components, assurez-vous que les éléments suivants sont sélectionnés :
      • MSVC v142 – VS 2019 C++ ARM64 build tools
      • C++ ATL for v142 build tools (ARM64)

Git Submodules

Certaines des dépendances sont contenues dans des submodules Git.Si vous n’avez pas passé l’option --recursive à git clone, vous devrez exécuter git submodule update --init.Chaque fois qu’un commit de submodule requis change (par exemple après git pull), vous devrez exécuter git submodule update.Si vous n’êtes pas sûr, exécutez git submodule update après chaque git pull, merge ou checkout.

Pour référence, les dépendances d’exécution suivantes sont incluses dans les submodules Git :

• eSpeak NG, version 1.51-dev commit 53915bf0a
• Sonic, commit 4f8c1d11
• IAccessible2, commit cbc1f29631780
• liblouis, version 3.17.0
• Unicode Common Locale Data Repository (CLDR), version 38.1
• NVDA images et sons
• Interface d’accessibilité d’Adobe Acrobat, version XI
• MinHook, tagué version 1.2.2
• brlapi Python bindings, version 0.8 ou ultérieure, distribué avec BRLTTY pour Windows, version 6.1
• lilli.dll, version 2.1.0.0
• Interface Python au pilote/puce FTDI
• Java Access Bridge 32 bit, de Zulu Community OpenJDK build 13.0.1+10Zulu (13.28.11)

En outre, les dépendances de temps de construction suivantes sont incluses dans le sous-module git miscDeps:

• txt2tags, version 2.5
• Nulsoft Install System, version 2.51
• NSIS UAC plug-in, version 0.2.4, ansi
• xgettext et msgfmt à partir de GNU gettext
• Boost Optional (en-tête autonome), à partir du commit 3922965

Les dépendances suivantes ne sont pas nécessaires à la plupart des gens, et ne sont pas incluses dans les sous-modules Git:

• Pour générer la documentation du développeur pour nvdaHelper : Doxygen Windows installer, version 1.8.15:

• Lorsque vous utilisez Visual Studio Code comme environnement de développement intégré de préférence, vous pouvez utiliser notre configuration d’espace de travail pré-remplie pour Visual Studio Code.Bien que ce projet VSCode ne soit pas inclus en tant que sous-module dans le référentiel NVDA, vous pouvez facilement vérifier la configuration de l’espace de travail dans votre référentiel en exécutant ce qui suit à partir de la racine du référentiel.

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

Dépendances Python

NVDA et son système de construction dépendent également d’une liste étendue de paquets Python. Ils sont tous listés avec leurs versions spécifiques dans un fichier requirements.txt à la racine de ce référentiel. Cependant, le système de construction se charge de les récupérer lui-même lorsque cela est nécessaire. ces paquets seront installés dans un environnement virtuel Python isolé au sein de ce dépôt, et n’affecteront pas votre ensemble de paquets à l’échelle du système.

Préparation de l’arbre source

Avant de pouvoir exécuter le code source de NVDA, vous devez préparer l’arbre source.Vous faites cela en ouvrant une invite de commande, en passant à la racine de la distribution source de NVDA et en tapant :

scons source

Vous devez refaire cela chaque fois que la version de comtypes change ou que des fichiers de langue sont ajoutés ou modifiés.Notez que si vous voulez accéder à la documentation utilisateur à partir du menu d’aide tout en exécutant la version source, vous devrez également ajouter user_docs à la ligne de commande comme suit:

scons source user_docs

Lorsqu’il s’agit simplement de tester ou de commettre des changements, il peut être plus rapide habituellement de juste faire scons source car la documentation utilisateur changera chaque fois que le numéro de révision change.

Compilation de NVDAHelper avec des options de débogage

Entre autres choses, la préparation de l’arbre source construit les bibliothèques de NVDAHelper.Si vous essayez de déboguer nvdaHelper, vous pouvez contrôler diverses options de débogage en construisant avec les variables de ligne de commande nvdaHelperDebugFlags et nvdaHelperLogLevel.

La variable nvdaHelperLogLevel spécifie le niveau de journalisation (0-59) que vous souhaitez voir, plus bas est plus verbeux. La valeur par défaut est 15.

La variable nvdaHelperDebugFlags prend un ou plusieurs des drapeaux suivants :

• debugCRT : les bibliothèques seront liées contre le runtime C de débogage et les assertions seront activées. (Par défaut, le CRT normal est utilisé et les assertions sont désactivées.)
• RTC : les vérifications d’exécution (corruption de pile, variables non initialisées, etc.) seront activées. (Par défaut, il n’y a pas de vérifications d’exécution.)
• analyze : exécute une analyse de code MSVC sur tout le code nvdaHelper, en holant sur tout avertissement. (La valeur par défaut est aucune analyse).

Les mots-clés spéciaux none et all peuvent également être utilisés à la place des drapeaux individuels.

Suit un exemple qui active les vérifications de débogage CRT et runtype

scons source nvdaHelperDebugFlags=debugCRT,RTC

Les fichiers pdb symboliques sont toujours produits lors de la construction, indépendamment des drapeaux de débogage.Cependant, ils ne sont pas inclus dans la distribution NVDA.Au lieu de cela, scons symbolsArchive les empaquetera comme une archive séparée.

Par défaut, les constructions n’utilisent également aucune optimisation du compilateur.Veuillez voir l’argument du mot clé release pour quelles optimisations du compilateur il activera.

Exécution du code source

Il est possible d’exécuter NVDA directement à partir des sources sans avoir à construire le paquet binaire complet et le lanceur.Pour lancer NVDA à partir des sources, en utilisant cmd.exe, exécutez runnvda.bat à la racine du dépôt.

Pour afficher l’aide sur les arguments que NVDA acceptera, utilisez l’option -h ou --help.Ces arguments sont également documentés dans le guide de l’utilisateur.

Construction de NVDA

Une construction binaire de NVDA peut être exécutée sur un système sans Python et toutes les autres dépendances de NVDA installées (comme nous le faisons pour les instantanés et les versions).

Des archives binaires et des bundles peuvent être créés en utilisant scons à partir de la racine de la distribution source de NVDA. Pour construire l’un des éléments suivants, ouvrez une invite de commande et passez dans ce répertoire.

Pour faire une construction binaire non archivée (équivalente à une archive portable extraite), tapez :

scons dist

La construction sera créée dans le répertoire dist.

Construction de l’installateur

Pour créer une archive de lancement (un exécutable permettant l’installation ou la génération de dist portable), tapez:

scons launcher

L’archive sera placée dans le répertoire de sortie.

Construction de la documentation du développeur

Pour générer le guide du développeur NVDA, tapez:

scons developerGuide

Le guide du développeur sera placé dans le dossier devDocs du répertoire de sortie.

Pour générer la documentation du code source basée sur HTML, tapez:

scons devDocs

La documentation sera placée dans le dossier NVDA du répertoire de sortie.

Pour générer la documentation du développeur pour nvdaHelper (non inclus dans la cible devDocs):

scons devDocs_nvdaHelper

La documentation sera placée dans le dossier devDocs\nvdaHelper du répertoire de sortie.

Générer une archive de symboles de débogage

Pour générer une archive de symboles de débogage pour les différents binaires dll/exe, tapez :

scons symbolsArchive

L’archive sera placée dans le répertoire de sortie.

Générer un modèle de traduction

Pour générer un modèle de traduction gettext (pour les traducteurs), tapez:

scons pot

Personnaliser la construction

Optionnellement, la construction peut être personnalisée en fournissant des variables sur la ligne de commande:

• version : La version de cette build.
• release : S’il s’agit d’une version release.
  • Cela permet d’activer diverses optimisations du compilateur C++ telles que /O2 et l’optimisation du programme entier.
  • Il indique également à Python de générer un code d’octet optimisé.
• publisher : L’éditeur de cette build.
• certFile : Le fichier de certificat avec lequel signer les exécutables. Le certificat doit être au format pfx et contenir la clé privée.
• certPassword : Le mot de passe pour la clé privée dans le certificat de signature. S’il est omis, aucun mot de passe ne sera supposé.
• certTimestampServer : L’URL du serveur d’horodatage à utiliser pour horodater les signatures authenticode. Si elle est omise, les signatures ne seront pas horodatées.
• outputDir : Le répertoire où seront placées les archives construites finales et autres.
• targetArchitectures : Les architectures cibles que NVDA doit prendre en charge. Les valeurs possibles sont all, x86 et x86_64. Ceci devrait généralement être laissé par défaut.

Par exemple, pour construire un lanceur avec une version spécifique, vous pourriez taper :

scons launcher version=test1

Pour en savoir plus, voir le fichier sconstruct.

Exécution de tests automatisés

Si vous apportez une modification au code de NVDA, vous devriez exécuter les tests automatisés de NVDA.Ces tests aident à garantir que les modifications du code ne cassent pas involontairement une fonctionnalité qui fonctionnait auparavant.

Pour exécuter les tests (tests unitaires, vérifications des chaînes traduisibles), changez d’abord de répertoire vers la racine de la distribution source de NVDA comme ci-dessus.Ensuite, exécutez :

scons tests

Tests unitaires

Pour exécuter uniquement des tests unitaires spécifiques, spécifiez-les en utilisant la variable unitTests sur la ligne de commande.Les tests doivent être fournis sous forme de liste séparée par des virgules.Chaque test doit être spécifié comme un module, une classe ou une méthode Python relatif au répertoire tests\unit.Par exemple, pour exécuter uniquement les méthodes des classes TestMove et TestSelection dans le fichier tests\unit\test_cursorManager.py, exécutez cette commande :

scons tests unitTests=test_cursorManager.TestMove,test_cursorManager.TestSelection

Contrôles des chaînes traduisibles

Pour exécuter uniquement les contrôles des chaînes traduisibles (qui vérifient que toutes les chaînes traduisibles ont des commentaires de traducteur), exécutez :

scons checkPot

Linting de vos modifications

Afin de vous assurer que vos modifications sont conformes au style de codage de NVDA, vous pouvez exécuter localement le linter Flake8.Certains développeurs ont trouvé certains messages d’erreur de linting trompeurs, ceux-ci sont clarifiés dans tests/lint/readme.md.runlint.bat utilisera Flake8 pour inspecter uniquement les différences entre votre répertoire de travail et la branche base spécifiée.Si vous créez une Pull Request, la branche base que vous utilisez ici devrait être la même que la cible que vous utiliseriez pour une Pull Request. Dans la plupart des cas, ce sera origin/master.

runlint origin/master

Pour être averti plus rapidement des erreurs de linting, vous pouvez souhaiter intégrer Flake8 d’autres outils de développement que vous utilisez.Pour plus de détails, voir tests/lint/readme.md

Tests unitaires

Les tests unitaires peuvent être exécutés avec le script rununittests.bat.En interne, ce script utilise le framework de test Python Nose pour exécuter les tests.Tout argument donné à rununittests.bat sont transmis à Nose.Veuillez vous référer à la documentation propre à Nose sur la façon de filtrer les tests, etc.

Tests système

Les tests système peuvent être exécutés avec le script runsystemtests.bat.En interne, ce script utilise le cadre de test Robot pour exécuter les tests.Tous les arguments donnés à runystemtests.bat sont transmis à Robot.Pour plus de détails (y compris le filtrage et l’exclusion des tests), voir tests/system/readme.md.

Contribution à NVDA

Si vous souhaitez contribuer au code ou à la documentation de NVDA, vous pouvez lire plus d’informations dans notre guide de contribution.