NVDA (NonVisual Desktop Access) ist ein freies, quelloffenes Bildschirmleseprogramm für Microsoft Windows, das von NV Access in Zusammenarbeit mit einer weltweiten Gemeinschaft von Mitwirkenden entwickelt wird.

Um mehr über NVDA zu erfahren oder eine Kopie herunterzuladen, besuchen Sie die NV Access-Hauptseite.

Bitte beachten Sie: Das NVDA-Projekt hat einen Verhaltenskodex für Bürger und Mitwirkende. NV Access erwartet, dass alle Mitwirkenden und andere Mitglieder der Gemeinschaft die in diesem Dokument dargelegten Regeln lesen und einhalten, wenn sie an diesem Projekt teilnehmen oder zu ihm beitragen.

Support erhalten

Ob Sie Anfänger oder fortgeschrittener Benutzer sind, ob Sie ein neuer oder langjähriger Entwickler sind, oder ob Sie eine Organisation sind, die mehr über NVDA wissen oder dazu beitragen möchte, Sie können Unterstützung durch die vorhandene Dokumentation sowie durch verschiedene Kommunikationskanäle erhalten, die speziell für den NVDA-Bildschirmleser eingerichtet wurden. Hier ist eine Übersicht über die wichtigsten Supportquellen.

Dokumentation

• NVDA User Guide
• NVDA Developer Guide
• NVDA Add- ons Development Internals
• NVDA ControllerClient Handbuch
• Weitere Dokumentation ist im Wiki dieses Repositorys und im Community Wiki

Kommunikationskanäle

• NVDA Users Mailing List
• NVDA Developers Mailing List
• NVDA Add- ons Mailing List
• ons Mailing List
• Instant Messaging channel for NVDA Support
• Other sources including groups and profiles on social media channels, Sprachspezifische Websites und Mailinglisten usw.

Sie können auch direkten Support von NV Access erhalten. Weitere Informationen finden Sie auf der NV Access Website.

Andere wichtige Projektlinks

• NVDA auf GitHub
• NVDA issues auf GitHub: Fehlerberichte, Feature Requests, etc.
• NVDA Entwicklungs-Snapshots: Automatisch generierte Builds des Projekts in seinem aktuellen Entwicklungsstadium
• NVDA Add-ons: Holen Sie sich Add-ons, um NVDA zu erweitern
• NVDA Add-ons Koordinations- und Support-Center: Alles über die NVDA Add-ons Umgebung
• NVDA Add-ons Template: Ein Repository zur Erstellung der Add-ons-Vorlage
• NVDA übersetzen: Informationen darüber, wie man NVDA in eine andere Sprache übersetzt
• NVDA Controller Client (2010-02-19): NVDA API für externe Anwendungen, um Nachrichten direkt zu sprechen oder in Blindenschrift zu schreiben, usw.
• Zu NVDA beitragen: Richtlinien für die Mitarbeit am NVDA-Quellcode
• NVDA commits email list: Benachrichtigungen für alle Übertragungen in das Git-Repository
• Alte E-Mail-Archive: enthalten Diskussionen über die NVDA-Entwicklung

Den Quellcode erhalten

Das NVDA-Projekt verwendet das Versionskontrollsystem Git für seinen Quellcode und die Dokumentation.

Das NVDA-Git-Repository befindet sich unter https://github.com/nvaccess/nvda.git. Sie können es mit dem folgenden Befehl klonen, der Dateien in einem Verzeichnis namens nvda ablegt:

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

Die Option --recursive wird benötigt, um verschiedene von uns verwendete Git-Submodule abzurufen.

Abhängigkeiten

Der NVDA-Quellcode hängt von mehreren anderen Paketen ab, um korrekt zu laufen.

Installierte Abhängigkeiten

Die folgenden Abhängigkeiten müssen auf Ihrem System installiert sein:

• Python, Version 3.8, 32 bit
  • Verwenden Sie nach Möglichkeit die neueste Nebenversion.
• Microsoft Visual Studio 2019 Community, Version 16.3 oder höher:
  • Download von https://visualstudio.microsoft.com/vs/
  • Bei der Installation von Visual Studio müssen Sie Folgendes aktivieren:
    • Auf der Registerkarte Arbeitslasten
      • in der Gruppe Windows:
        • Desktop-Entwicklung mit C++
      • Dann stellen Sie im Abschnitt Installationsdetails unter Desktop für C++, Optionale Gruppierung, sicher, dass Folgendes ausgewählt ist:
        • MSVC v142 – VS 2019 C++ x64/x86 build tools
        • Windows 10 SDK (10.0.19041.0)
        • C++ ATL für v142 build tools (x86 & x64)
        • C++ Clang tools for Windows
    • Stellen Sie sicher, dass auf der Registerkarte „Einzelne Komponenten“ die folgenden Elemente ausgewählt sind:
      • MSVC v142 – VS 2019 C++ ARM64 build tools
      • C++ ATL für v142 build tools (ARM64)

Git Submodules

Einige der Abhängigkeiten sind in Git Submodules enthalten.Wenn Sie die Option --recursive nicht an git clone übergeben haben, müssen Sie git submodule update --init ausführen.Wann immer sich ein erforderlicher Submodul-Commit ändert (z. B. nach einem Git-Pull), müssen Sie git submodule update ausführen. Wenn Sie sich nicht sicher sind, führen Sie git submodule update nach jedem Git-Pull, Merge oder Checkout aus.

Als Referenz sind die folgenden Laufzeitabhängigkeiten in Git-Submodulen enthalten:

• 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 and sounds
• Adobe Acrobat accessibility interface, Version XI
• MinHook, tagged version 1.2.2
• brlapi Python bindings, Version 0.8 oder höher, verteilt mit BRLTTY für Windows, Version 6.1
• lilli.dll, Version 2.1.0.0
• Python Schnittstelle zu FTDI Treiber/Chip
• Java Access Bridge 32 bit, von Zulu Community OpenJDK build 13.0.1+10Zulu (13.28.11)

Zusätzlich sind die folgenden Abhängigkeiten zur Erstellungszeit im miscDeps git Submodul enthalten:

• txt2tags, Version 2.5
• Nulsoft Install System, Version 2.51
• NSIS UAC plug-in, Version 0.2.4, ansi
• xgettext und msgfmt von GNU gettext
• Boost Optional (eigenständiger Header), aus Commit 3922965

Die folgenden Abhängigkeiten werden von den meisten Leuten nicht benötigt und sind nicht in Git-Submodulen enthalten:

• Um Entwicklerdokumentation für nvdaHelper zu generieren: Doxygen Windows Installer, Version 1.8.15:

• Wenn Sie Visual Studio Code als Ihre bevorzugte integrierte Entwicklungsumgebung verwenden, können Sie unsere vorgefertigte Arbeitsbereichskonfiguration für Visual Studio Code nutzen.Dieses VSCode-Projekt ist zwar nicht als Submodul im NVDA-Repository enthalten, aber Sie können die Workspace-Konfiguration ganz einfach in Ihrem Repository überprüfen, indem Sie den folgenden Befehl im Stammverzeichnis des Repositorys ausführen.

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

Python-Abhängigkeiten

NVDA und sein Build-System hängen auch von einer umfangreichen Liste von Python-Paketen ab. Sie sind alle mit ihren spezifischen Versionen in einer requirements.txt-Datei im Stammverzeichnis dieses Repositorys aufgeführt. Diese Pakete werden in eine isolierte virtuelle Python-Umgebung innerhalb dieses Repositorys installiert und haben keinen Einfluss auf die systemweite Menge an Paketen.

Vorbereiten des Quellbaums

Bevor Sie den NVDA-Quellcode ausführen können, müssen Sie den Quellbaum vorbereiten, indem Sie eine Eingabeaufforderung öffnen, zum Stammverzeichnis der NVDA-Quelldistribution wechseln und Folgendes eingeben:

scons source

Sie sollten dies jedes Mal wiederholen, wenn sich die Version von comtypes ändert oder Sprachdateien hinzugefügt oder geändert werden.Beachten Sie, dass Sie, wenn Sie auf die Benutzerdokumentation über das Hilfemenü zugreifen möchten, während Sie die Quellversion ausführen, auch user_docs zur Befehlszeile hinzufügen müssen, und zwar wie folgt:

scons source user_docs

Wenn Sie einfach nur Änderungen testen oder übertragen, kann es schneller sein, einfach scons source einzugeben, da sich die Benutzerdokumentation jedes Mal ändert, wenn sich die Revisionsnummer ändert.

Kompilieren von NVDAHelper mit Debugging-Optionen

Unter anderem werden durch das Vorbereiten des Quellbaums die NVDAHelper-Bibliotheken gebaut.

Wenn man versucht, nvdaHelper zu debuggen, kann man verschiedene Debugging-Optionen steuern, indem man mit den nvdaHelperDebugFlags und nvdaHelperLogLevel Kommandozeilenvariablen baut.

Die nvdaHelperLogLevelVariable gibt den gewünschten Logging-Level (0-59) an, niedriger ist ausführlicher. Die Voreinstellung ist 15.

Die nvdaHelperDebugFlags-Variable nimmt einen oder mehrere der folgenden Flags auf:

• debugCRT: Die Bibliotheken werden gegen die Debug-C-Laufzeit gelinkt und Assertions werden aktiviert. (Standardmäßig wird die normale CRT verwendet und Assertions sind deaktiviert.)
• RTC: Laufzeitprüfungen (Stack Corruption, uninitialisierte Variablen, etc.) werden aktiviert. (Standardmäßig sind keine Laufzeitprüfungen aktiviert.)
• analyze: Führt eine MSVC-Code-Analyse des gesamten nvdaHelper-Codes durch und hält bei jeder Warnung an. (Standard ist keine Analyse).

Die speziellen Schlüsselwörter none und all können auch anstelle der einzelnen Flags verwendet werden.

Es folgt ein Beispiel, das Debug-CRT- und Runtime-Checks aktiviert

scons source nvdaHelperDebugFlags=debugCRT,RTC

Symbol-pdb-Dateien werden beim Bauen immer erzeugt, unabhängig von den Debug-Flags.Sie sind jedoch nicht in der NVDA-Distribution enthalten, sondern werden mit scons symbolsArchive in ein separates Archiv gepackt.

Standardmäßig verwenden die Builds auch keine Compiler-Optimierungen, siehe das release-Schlüsselwortargument für die aktivierten Compiler-Optimierungen.

Ausführen des Quellcodes

Es ist möglich, NVDA direkt aus dem Quellcode zu starten, ohne das komplette Binärpaket und den Launcher bauen zu müssen.

Um NVDA aus dem Quellcode zu starten, verwenden Sie cmd.exe, führen Sie runnvda.bat in der Wurzel des Repositorys aus.

Um Hilfe zu den Argumenten zu erhalten, die NVDA akzeptiert, verwenden Sie die Option -h oder --help.Diese Argumente sind auch im Benutzerhandbuch dokumentiert.

Erstellen von NVDA

Ein binäres Build von NVDA kann auf einem System ausgeführt werden, auf dem Python und alle anderen Abhängigkeiten von NVDA nicht installiert sind (wie es bei Snapshots und Releases der Fall ist).

Binärarchive und Bundles können mit scons aus dem Stammverzeichnis der NVDA-Quelldistribution erstellt werden. Um eines der folgenden Pakete zu erstellen, öffnen Sie eine Eingabeaufforderung und wechseln Sie in dieses Verzeichnis.

Um ein nicht archiviertes Binärpaket zu erstellen (entspricht einem entpackten portablen Archiv), geben Sie Folgendes ein:

scons dist

Das Paket wird im Verzeichnis dist erstellt.

Erstellen des Installers

Um ein Launcher-Archiv zu erstellen (eine ausführbare Datei, die die Installation oder die Erstellung eines portablen dist-Archivs ermöglicht), geben Sie ein:

scons launcher

Das Archiv wird in das Ausgabeverzeichnis gelegt.

Erstellen der Entwicklerdokumentation

Um das NVDA-Entwicklerhandbuch zu erstellen, geben Sie ein:

scons developerGuide

Das Entwicklerhandbuch wird im Ordner devDocs im Ausgabeverzeichnis abgelegt.

Um die HTML-basierte Quellcodedokumentation zu erstellen, geben Sie ein:

scons devDocs

Die Dokumentation wird im Ordner NVDA im Ausgabeverzeichnis abgelegt.

Um Entwicklerdokumentation für nvdaHelper zu generieren (nicht im devDocs-Ziel enthalten):

scons devDocs_nvdaHelper

Die Dokumentation wird im Ordner devDocs\nvdaHelper im Ausgabeverzeichnis abgelegt.

Generate debug symbols archive

Um ein Archiv mit Debugsymbolen für die verschiedenen dll/exe-Binärdateien zu generieren, geben Sie ein:

scons symbolsArchive

Das Archiv wird im Ausgabeverzeichnis abgelegt.

Übersetzungsvorlage generieren

Um eine gettext-Übersetzungsvorlage (für Übersetzer) zu generieren, geben Sie ein:

scons pot

Anpassen des Builds

Optional kann der Build durch Angabe von Variablen auf der Befehlszeile angepasst werden:

• version: Die Version dieses Builds.
• release: Ob es sich um eine Release-Version handelt.
  • Dies aktiviert verschiedene C++-Compiler-Optimierungen wie /O2 und Ganzprogramm-Optimierung.
  • Es weist auch Python an, optimierten Byte-Code zu erzeugen.
• Verlag: Der Herausgeber dieses Builds.
• certFile: Die Zertifikatsdatei, mit der ausführbare Dateien signiert werden sollen. Das Zertifikat muss im pfx-Format vorliegen und den privaten Schlüssel enthalten.
• certPassword: Das Passwort für den privaten Schlüssel im Signierzertifikat. Wird es weggelassen, wird kein Passwort angenommen.
• certTimestampServer: Die URL des Zeitstempelservers, der für die Zeitstempelung von Authenticode-Signaturen verwendet wird. Wird dieser Parameter nicht angegeben, werden die Signaturen nicht mit einem Zeitstempel versehen.
• outputDir: Das Verzeichnis, in dem die endgültigen Archive und dergleichen abgelegt werden.
• targetArchitectures: Die Zielarchitekturen, die NVDA unterstützen soll. Mögliche Werte sind all, x86 und x86_64. Dies sollte im Allgemeinen als Voreinstellung belassen werden.

Um beispielsweise einen Launcher mit einer bestimmten Version zu erstellen, können Sie Folgendes eingeben:

scons launcher version=test1

Weitere Informationen finden Sie in der Datei sconstruct.

Automatisierte Tests ausführen

Wenn Sie eine Änderung am NVDA-Code vornehmen, sollten Sie die automatisierten Tests von NVDA ausführen.

Diese Tests helfen sicherzustellen, dass Codeänderungen nicht unbeabsichtigt Funktionen zerstören, die zuvor funktionierten.

Um die Tests (Unit-Tests, Überprüfungen der übersetzbaren Zeichenketten) auszuführen, wechseln Sie zunächst in das Stammverzeichnis der NVDA-Quelldistribution (siehe oben) und führen Sie dann Folgendes aus:

scons tests

Unit-Tests

Um nur bestimmte Unit-Tests auszuführen, geben Sie diese mit der Variablen unitTests in der Befehlszeile an.Um zum Beispiel nur Methoden in den Klassen TestMove und TestSelection in der Datei tests\unit\test_cursorManager.py auszuführen, führen Sie diesen Befehl aus:

scons tests unitTests=test_cursorManager.TestMove,test_cursorManager.TestSelection

Prüfungen für übersetzbare Zeichenfolgen

Um nur die Prüfungen für übersetzbare Zeichenfolgen auszuführen (die prüfen, ob alle übersetzbaren Zeichenfolgen Übersetzerkommentare haben), führen Sie aus:

scons checkPot

Linting Ihrer Änderungen

Um sicherzustellen, dass Ihre Änderungen dem Kodierungsstil von NVDA entsprechen, können Sie den Flake8-Linter lokal ausführen.Einige Entwickler haben bestimmte Linting-Fehlermeldungen als irreführend empfunden, diese werden in tests/lint/readme.md erläutert.runlint.bat verwendet Flake8, um nur die Unterschiede zwischen Ihrem Arbeitsverzeichnis und dem angegebenen base-Zweig zu untersuchen. Wenn Sie einen Pull Request erstellen, sollte der base-Zweig, den Sie hier verwenden, derselbe sein wie das Ziel, das Sie für einen Pull Request verwenden würden. In den meisten Fällen wird es origin/master sein.

runlint origin/master

Um schneller vor Linting-Fehlern gewarnt zu werden, können Sie Flake8 in andere Entwicklungswerkzeuge, die Sie verwenden, integrieren.tests/lint/readme.md

Unit-Tests

Unit-Tests können mit dem Skript rununittests.bat ausgeführt werden.rununittests.bat Intern verwendet dieses Skript das Python-Test-Framework Nose, um die Tests auszuführen.rununittests.batAlle Argumente, die an rununittests.Alle Argumente, die rununittests.bat übergeben werden, werden an Nose weitergeleitet.

Systemtests

Systemtests können mit dem Skript runsystemtests.bat ausgeführt werden.

Systemtests können mit dem Skript runsystemtests.bat ausgeführt werden.

Systemtests können mit dem Skript runsystemtests.bat ausgeführt werden.

Systemtests können mit dem Skript runsystemtests.bat ausgeführt werden.

Systemtests können mit dem Skript runsystemtests.bat ausgeführt werden.

Systemtests können mit dem Skript runsystemtests.bat ausgeführt werden.

Zu NVDA beitragen

Wenn Sie Code oder Dokumentation zu NVDA beisteuern möchten, finden Sie weitere Informationen in unserem Leitfaden zur Mitarbeit.