NVDA (NonVisual Desktop Access) är en fri skärmläsare med öppen källkod för Microsoft Windows.Den utvecklas av NV Access i samarbete med en global gemenskap av bidragsgivare.Om du vill veta mer om NVDA eller ladda ner ett exemplar kan du besöka NV Access huvudwebbplats.

Vänligen notera: NVDA-projektet har en uppförandekod för medborgare och bidragsgivare. NV Access förväntar sig att alla bidragsgivare och andra medlemmar av gemenskapen läser och följer de regler som anges i detta dokument när de deltar eller bidrar till detta projekt.

Få stöd

Oavsett om du är nybörjare, avancerad användare, ny eller gammal utvecklare, eller om du är en organisation som vill veta mer eller bidra till NVDA, kan du få stöd genom den dokumentation som finns på plats samt flera kommunikationskanaler som är dedikerade för NVDA skärmläsare. Här är en översikt över de viktigaste stödkällorna.

Dokumentation

• NVDA User Guide
• NVDA Developer Guide
• NVDA Add-ons Development Internals
• NVDA ControllerClient manual
• Det finns ytterligare dokumentation i Wiki för detta arkiv och i Community Wiki

Kommunikationskanaler

• NVDA Users Mailing List
• NVDA Developers Mailing List
• NVDA Add-ons Mailing List
• Instant Messaging channel for NVDA Support
• Andra källor, inklusive grupper och profiler i sociala medier, språkspecifika webbplatser och sändlistor etc.

Du kan också få direkt support från NV Access. Se NV Access-webbplatsen för mer information.

Andra viktiga projektlänkar

• NVDA på GitHub
• NVDA-frågor på GitHub: Bug reports, feature requests, etc.
• NVDA development snapshots: Automatiskt genererade byggs upp av projektet i dess nuvarande utvecklingsläge
• NVDA-tillägg: NVDA-tillägg: Få tillägg för att förbättra NVDA
• NVDA Add-ons coordination and support center: Allt om NVDA:s tilläggsmiljö
• NVDA Add-ons Template: Ett arkiv för att generera mallen för tilläggsmoduler
• Översättning av NVDA: Information om hur man översätter NVDA till ett annat språk
• NVDA Controller Client (2010-02-19): Information om hur man översätter NVDA till ett annat språk
• NVDA Controller Client (2010-02-19): NVDA API för externa program för att direkt tala eller punktskriftsanpassa meddelanden etc.
• Bidra till NVDA: Riktlinjer för att bidra till NVDA:s källkod
• NVDA commits email list: Notiser om alla ändringar i Git-arkivet
• Gamla e-postarkiv: Innehåller diskussioner om NVDA-utveckling

Få tag på källkoden

NVDA-projektet använder versionskontrollsystemet Git för sin källkod och dokumentation.

NVDA:s Git-arkiv finns på https://github.com/nvaccess/nvda.git. Du kan klona det med följande kommando, vilket kommer att placera filer i en katalog som heter nvda:

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

Optionen --recursive behövs för att hämta olika Git-submoduler som vi använder.

Beroenden

Källkoden till NVDA är beroende av flera andra paket för att fungera korrekt.

Installerade beroenden

Följande beroenden måste installeras på ditt system:

• Python, version 3.8, 32 bit
  • Använd senaste mindre version om möjligt.
• Microsoft Visual Studio 2019 Community, version 16.3 eller senare:
  • Hämta från https://visualstudio.microsoft.com/vs/
  • När du installerar Visual Studio måste du aktivera följande:
    • På fliken Arbetsbelastningar
      • i gruppen Windows:
        • Desktop development with C++
      • I avsnittet Installationsdetaljer, under Desktop for C++, Optional grouping, säkerställer du att följande är markerat:
        • 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-verktyg för Windows
    • På fliken Enskilda komponenter ser du till att följande objekt är valda:
      • MSVC v142 – VS 2019 C++ ARM64 build tools
      • C++ ATL for v142 build tools (ARM64)

Git Submodules

En del av beroendena finns i Git submodules.Om du inte har lämnat alternativet --recursive till git clone måste du köra git submodule update --init.Närhelst en nödvändig undermodul commit ändras (t.ex. efter git pull) måste du köra git submodule update.Om du inte är säker, kör git submodule update efter varje git pull, merge eller checkout.

För referens är följande körtidsberoenden inkluderade i Git-submoduler:

• 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 bilder och ljud
• Adobe Acrobat tillgänglighetsgränssnitt, version XI
• MinHook, taggad version 1.2.2
• brlapi Python bindningar, version 0.8 eller senare, distribuerad med BRLTTY för Windows, version 6.1
• lilli.dll, version 2.1.0.0
• Pythongränssnitt till FTDI-drivrutin/chip
• Java Access Bridge 32 bit, från Zulu Community OpenJDK build 13.0.1+10Zulu (13.28.11)

Den miscDeps git-submodulen innehåller dessutom följande byggtidsberoenden:

• txt2tags, version 2.5
• Nulsoft Install System, version 2.51
• NSIS UAC plug-in, version 0.2.4, ansi
• xgettext och msgfmt från GNU gettext
• Boost Optional (stand-alone header), från commit 3922965

Följande beroenden behövs inte av de flesta och ingår inte i Git-undermoduler:

• För att generera utvecklardokumentation för nvdaHelper: Doxygen Windows installer, version 1.8.15:

• När du använder Visual Studio Code som den integrerade utvecklingsmiljön som du föredrar kan du använda dig av vår förbeställda arbetsrumskonfiguration för Visual Studio Code.Även om det här VSCode-projektet inte ingår som en undermodul i NVDA:s arkiv kan du enkelt kontrollera arbetsrumskonfigurationen i ditt arkiv genom att köra följande från roten av arkivet.

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

Python-beroenden

NVDA och dess byggsystem är också beroende av en omfattande lista med Python-paket. De listas alla med sina specifika versioner i en requirements.txt-fil i roten av detta arkiv. Byggsystemet tar dock hand om att hämta dessa själv när det behövs. dessa paket kommer att installeras i en isolerad virtuell Python-miljö i detta arkiv och kommer inte att påverka din paketuppsättning för hela systemet.

Förberedelse av källkodsträdet

För att kunna köra NVDA-källkoden måste du förbereda källkodsträdet. detta gör du genom att öppna en kommandotolk, byta till roten av NVDA-källkoddistributionen och skriva:

scons source

Du bör göra detta igen varje gång versionen av comtypes ändras eller språkfiler läggs till eller ändras.Observera att om du vill komma åt användardokumentation från hjälpmenyn när du kör källversionen måste du också lägga till user_docs på kommandoraden på följande sätt:

scons source user_docs

När du bara testar eller bekräftar ändringar kan det vara snabbare att bara göra scons source eftersom användardokumentationen kommer att ändras varje gång revisionsnumret ändras.

Kompilera NVDAHelper med felsökningsalternativ

Av bland annat att förbereda källkodsträdet bygger NVDAHelper-biblioteken.Om du försöker felsöka nvdaHelper kan du styra olika felsökningsalternativ genom att bygga med kommandoradsvariablerna nvdaHelperDebugFlags och nvdaHelperLogLevel.

Variabeln nvdaHelperLogLevel anger vilken nivå på loggningen (0-59) du vill se, lägre är mer utförlig. Standardvärdet är 15.

Variabeln nvdaHelperDebugFlags tar en eller flera av följande flaggor:

• debugCRT: biblioteken kommer att länkas mot debug C runtime och assertions kommer att aktiveras. (Som standard används den normala CRT och assertions är inaktiverade.)
• RTC: Kontroller av körtiden (stackkorruption, oinitialiserade variabler etc.) kommer att aktiveras. (Standard är inga körtidskontroller.)
• analyze: kör MSVC-kodanalys på all nvdaHelper-kod och holar vid varje varning. (Standard är ingen analys).

De speciella nyckelorden none och all kan också användas i stället för de enskilda flaggorna.

Ett exempel följer som aktiverar debug CRT- och runtype-kontroller

scons source nvdaHelperDebugFlags=debugCRT,RTC

Symbol-pdb-filer produceras alltid vid byggandet, oavsett debug-flaggor.De ingår dock inte i NVDA-distributionen.Istället kommer scons symbolsArchive att paketera dem som ett separat arkiv.

Som standard använder byggningarna inte heller några kompilatoroptimeringar.Se nyckelordet release för att se vilka kompilatoroptimeringar som kommer att aktiveras.

Kör källkod

Det är möjligt att köra NVDA direkt från källkod utan att behöva bygga hela det binära paketet och startprogrammet.För att starta NVDA från källkod, med hjälp av cmd.exe, kör runnvda.bat i roten av arkivet.

För att få hjälp med de argument som NVDA kommer att acceptera, använd alternativet -h eller --help.Dessa argument finns också dokumenterade i användarhandboken.

Bygga NVDA

En binärbyggnad av NVDA kan köras på ett system utan att Python och alla NVDA:s andra beroenden är installerade (vilket vi gör för ögonblicksbilder och utgåvor).

Binära arkiv och buntar kan skapas med hjälp av scons från roten av NVDA:s källdistribution. För att bygga något av följande öppnar du en kommandotolk och byter till den här katalogen.

För att göra ett binärt bygge som inte är arkiverat (motsvarande ett extraherat portabelt arkiv) skriver du:

scons dist

Bygget kommer att skapas i dist-katalogen.

Bygga installationsprogrammet

För att skapa ett startarkivet (en körbar fil som möjliggör installation eller generering av portabel dist), skriv:

scons launcher

Arkivet kommer att placeras i utdatakatalogen.

Byggande av utvecklardokumentation

För att generera NVDA-utvecklarguiden skriver du:

scons developerGuide

Utvecklarguiden placeras i mappen devDocs i utdatakatalogen.

För att generera den HTML-baserade källkodsdokumentationen skriver du:

scons devDocs

Dokumentationen placeras i mappen NVDA i utdatakatalogen.

För att generera utvecklardokumentation för nvdaHelper (ingår inte i devDocs-målet):

scons devDocs_nvdaHelper

Dokumentationen kommer att placeras i mappen devDocs\nvdaHelper i utdatakatalogen.

Generera arkiv för felsymboler

För att generera ett arkiv med felsymboler för de olika binärerna dll/exe skriver du:

scons symbolsArchive

Arkivet kommer att placeras i utdatakatalogen.

Generera översättningsmall

För att generera en gettext-översättningsmall (för översättare), skriv:

scons pot

Anpassa byggningen

Optionellt kan byggningen anpassas genom att ange variabler på kommandoraden:

• version:
• release: Den här versionen av den här byggnaden.
• release: Den här versionen av den här byggnaden: Om detta är en releaseversion.
  • Detta aktiverar olika optimeringar av C++-kompilatorn såsom /O2 och optimering av hela program.
  • Det instruerar också Python att generera optimerad byte-kod.
• publisher: Utgivaren för den här byggnaden.
• certFile: Certifikatfilen som ska användas för att signera körbara filer. Certifikatet måste vara i pfx-format och innehålla den privata nyckeln.
• certPassword: Lösenordet för den privata nyckeln i signeringscertifikatet. Om det utelämnas antas inget lösenord.
• certTimestampServer: URL för den tidsstämplingsserver som ska användas för att tidsstämpla autentiska signaturer. Om den utelämnas kommer signaturerna inte att tidsstämplas.
• outputDir: Katalogen där de slutgiltigt byggda arkiven och liknande kommer att placeras.
• targetArchitectures: De målarkitekturer som NVDA ska ha stöd för. Möjliga värden är all, x86 och x86_64. Detta bör i allmänhet lämnas som standard.

För att till exempel bygga en launcher med en viss version kan du skriva:

scons launcher version=test1

För mer information se sconstruct-filen.

Kör automatiserade tester

Om du gör en ändring i NVDA-koden bör du köra NVDA:s automatiserade tester.Dessa tester hjälper till att se till att kodändringar inte oavsiktligt bryter funktionalitet som tidigare fungerade.

För att köra testerna (enhetstester, kontroller av översättningsbara strängar) byter du först katalog till roten av NVDA:s källkodsdistribution enligt ovan.Kör sedan:

scons tests

Enhetstester

För att köra endast specifika enhetstester specificerar du dem med hjälp av unitTests-variabeln på kommandoraden.Testerna ska anges i form av en lista med kommatecken som åtskiljs av varandra.Varje test ska specificeras som en Pythonmodul, -klass eller -metod relativt till tests\unit-katalogen.Om du till exempel bara vill köra metoder i klasserna TestMove och TestSelection i filen tests\unit\test_cursorManager.py kör du det här kommandot:

scons tests unitTests=test_cursorManager.TestMove,test_cursorManager.TestSelection

Kontroller av översättningsbara strängar

För att bara köra kontrollerna av översättningsbara strängar (som kontrollerar att alla översättningsbara strängar har översättarkommentarer) kör du:

scons checkPot

Lintning av dina ändringar

För att säkerställa att dina ändringar överensstämmer med NVDA:s kodningsstil kan du köra Flake8 linter lokalt.Vissa utvecklare har tyckt att vissa felmeddelanden för linting är missvisande, dessa förtydligas i tests/lint/readme.md.runlint.bat använder Flake8 för att inspektera endast skillnaderna mellan din arbetskatalog och den angivna base-grenen.Om du skapar en Pull Request bör base-grenen du använder här vara densamma som det mål du skulle använda för en Pull Request. I de flesta fall är det origin/master.

runlint origin/master

För att snabbare bli varnad för lintingfel kan du integrera Flake8 andra utvecklingsverktyg som du använder.För mer information, se tests/lint/readme.md

Enhetstester

Enhetstester kan köras med skriptet rununittests.bat.Internt använder det här skriptet Nose Python-testramverket för att köra testerna.Alla argument som ges till rununittests.bat vidarebefordras till Nose.Se Nose’s egen dokumentation om hur man filtrerar tester etc.

Systemtester

Systemtester kan köras med skriptet runsystemtests.bat.Internt använder det här skriptet Robot-testramverket för att utföra testerna.Alla argument som ges till runsystemtests.bat vidarebefordras till Robot.För mer information (inklusive filtrering och exkludering av tester), se tests/system/readme.md.

Bidra till NVDA

Om du vill bidra med kod eller dokumentation till NVDA kan du läsa mer information i vår guide för bidrag.