nvaccess / nvda

NVDA (NonVisual Desktop Access) è un lettore di schermo libero e open source per Microsoft Windows, sviluppato da NV Access in collaborazione con una comunità globale di collaboratori. NV Access si aspetta che tutti i collaboratori e gli altri membri della comunità leggano e rispettino le regole stabilite in questo documento mentre partecipano o contribuiscono a questo progetto.

Avere supporto

Se sei un principiante, un utente avanzato, uno sviluppatore nuovo o di lunga data, o se sei un’organizzazione che vuole saperne di più o contribuire a NVDA, puoi ottenere supporto attraverso la documentazione esistente e i diversi canali di comunicazione dedicati allo screen reader NVDA. Ecco una panoramica delle fonti di supporto più importanti.

Documentazione

  • Guida utente NVDA
  • Guida sviluppatore NVDA
  • NVDA Add-Sviluppo Internals
  • Manuale ControllerClient
  • Altra documentazione è inclusa nel Wiki di questo repository e nel Community Wiki

Canali di comunicazione

  • Mail List di utenti NVDA
  • Mail List di sviluppatori NVDA
  • Mail List di Add-Mailing List
  • Canale di messaggistica istantanea per il supporto di NVDA
  • Altre fonti tra cui gruppi e profili sui canali dei social media, siti web e mailing list specifiche per la lingua, ecc.

Puoi anche ottenere supporto diretto da NV Access. Vedi il sito web di NV Access per maggiori dettagli.

Altri link chiave del progetto

  • NVDA su GitHub
  • Problemi di NVDA su GitHub: Segnalazioni di bug, richieste di caratteristiche, ecc.
  • Istantanee di sviluppo di NVDA: Costruzioni generate automaticamente del progetto nel suo attuale stato di sviluppo
  • NVDA add-ons: Ottenere componenti aggiuntivi per migliorare NVDA
  • NVDA Add-ons coordination and support center: tutto sull’ambiente degli addons di NVDA
  • NVDA Add-ons Template: Un repository per generare il template Add-ons
  • Tradurre NVDA: Informazioni su come tradurre NVDA in un’altra lingua
  • NVDA Controller Client (2010-02-19): API di NVDA per applicazioni esterne per parlare direttamente o messaggi in braille, ecc.
  • Contribuire a NVDA: Linee guida per contribuire al codice sorgente di NVDA
  • NVDA commits email list: Notifiche per tutti i commit al repository Git
  • Vecchi archivi email: contengono discussioni sullo sviluppo di NVDA

Ottenere il codice sorgente

Il progetto NVDA utilizza il sistema di controllo di versione Git per il suo codice sorgente e la documentazione.

Il repository Git di NVDA si trova a https://github.com/nvaccess/nvda.git. Puoi clonarlo con il seguente comando, che metterà i file in una directory chiamata nvda:

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

L’opzione --recursive è necessaria per recuperare i vari sottomoduli Git che usiamo.

Dipendenze

Il sorgente NVDA dipende da diversi altri pacchetti per funzionare correttamente.

Dipendenze installate

Le seguenti dipendenze devono essere installate sul tuo sistema:

  • Python, versione 3.8, 32 bit
    • Usa l’ultima versione minore se possibile.
  • Microsoft Visual Studio 2019 Community, versione 16.3 o successiva:
    • Scaricare da https://visualstudio.microsoft.com/vs/
    • Quando si installa Visual Studio, è necessario abilitare quanto segue:
      • Nella scheda Carichi di lavoro
        • nel gruppo Windows:
          • Sviluppo desktop con C++
        • Poi nella sezione Dettagli dell’installazione, sotto Desktop per C++, raggruppamento opzionale, assicurati che siano selezionati i seguenti:
          • MSVC v142 – VS 2019 C++ x64/x86 build tools
          • Windows 10 SDK (10.0.19041.0)
          • C++ ATL per strumenti di build v142 (x86 & x64)
          • Strumenti C++ Clang per Windows
      • Nella scheda Componenti individuali, assicurarsi che le seguenti voci siano selezionate:
        • MSVC v142 – VS 2019 C++ ARM64 build tools
        • C++ ATL per v142 build tools (ARM64)

Git Submodules

Alcune dipendenze sono contenute in Git submodules.Se non hai passato l’opzione --recursive a git clone, dovrai eseguire git submodule update --init.Ogni volta che il commit di un sottomodulo richiesto cambia (ad esempio dopo un git pull), dovrai eseguire git submodule update.Se non sei sicuro, esegui git submodule update dopo ogni git pull, merge o checkout.

Per riferimento, le seguenti dipendenze sono incluse nei sottomoduli Git:

  • eSpeak NG, versione 1.51-dev commit 53915bf0a
  • Sonic, commit 4f8c1d11
  • IAccessible2, commit cbc1f29631780
  • liblouis, versione 3.17.0
  • Unicode Common Locale Data Repository (CLDR), versione 38.1
  • NVDA immagini e suoni
  • Interfaccia di accessibilità di Adobe Acrobat, versione XI
  • MinHook, tagged versione 1.2.2
  • brlapi Python bindings, versione 0.8 o successiva, distribuito con BRLTTY per Windows, versione 6.1
  • lilli.dll, versione 2.1.0.0
  • interfaccia Python al driver/chip FTDI
  • Java Access Bridge 32 bit, da Zulu Community OpenJDK build 13.0.1+10Zulu (13.28.11)

Inoltre, le seguenti dipendenze del tempo di costruzione sono incluse nel sottomodulo git miscDeps:

  • txt2tags, versione 2.5
  • Nulsoft Install System, versione 2.51
  • NSIS UAC plug-in, versione 0.2.4, ansi
  • xgettext e msgfmt da GNU gettext
  • Boost Optional (header stand-alone), dal commit 3922965

Le seguenti dipendenze non sono necessarie alla maggior parte delle persone, e non sono incluse nei sottomoduli Git:

  • Per generare documentazione per sviluppatori per nvdaHelper: Doxygen Windows installer, versione 1.8.15:

  • Quando usi Visual Studio Code come ambiente di sviluppo integrato di preferenza, puoi fare uso della nostra configurazione prepopolata dello spazio di lavoro per Visual Studio Code.Anche se questo progetto VSCode non è incluso come sottomodulo nel repository di NVDA, puoi facilmente controllare la configurazione dello spazio di lavoro nel tuo repository eseguendo quanto segue dalla root del repository.

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

Dipendenze Python

NVDA e il suo sistema di compilazione dipendono anche da un ampio elenco di pacchetti Python. Sono tutti elencati con le loro versioni specifiche in un file requirements.txt nella root di questo repository. Questi pacchetti saranno installati in un ambiente virtuale Python isolato all’interno di questo repository, e non influenzeranno il tuo insieme di pacchetti a livello di sistema.

Preparare l’albero dei sorgenti

Prima di poter eseguire il codice sorgente di NVDA, è necessario preparare l’albero dei sorgenti, aprendo un prompt dei comandi, passando alla radice della distribuzione dei sorgenti di NVDA e digitando:

scons source

Si dovrebbe rifare questa operazione ogni volta che la versione di comtypes cambia o vengono aggiunti o modificati dei file di lingua.Nota che se vuoi accedere alla documentazione utente dal menu di aiuto mentre stai eseguendo la versione sorgente, dovrai anche aggiungere user_docs alla linea di comando in questo modo:

scons source user_docs

Mentre stai semplicemente testando o impegnando le modifiche, potrebbe essere più veloce di solito fare solo scons source poiché la documentazione utente cambierà ogni volta che cambia il numero di revisione.

Compilazione di NVDAHelper con opzioni di debug

Tra le altre cose, la preparazione dell’albero dei sorgenti costruisce le librerie NVDAHelper.Se si cerca di fare il debug di nvdaHelper, è possibile controllare varie opzioni di debug costruendo con le variabili nvdaHelperDebugFlags e nvdaHelperLogLevel della linea di comando.

La variabile nvdaHelperLogLevel specifica il livello di log (0-59) che si desidera vedere, più basso è più prolisso. Il valore predefinito è 15.

La variabile nvdaHelperDebugFlags accetta uno o più dei seguenti flag:

  • debugCRT: le librerie saranno collegate al runtime C di debug e le asserzioni saranno abilitate. (Per impostazione predefinita, viene usato il normale CRT e le asserzioni sono disabilitate.)
  • RTC: i controlli di runtime (corruzione dello stack, variabili non inizializzate, ecc.) saranno abilitati. (l’impostazione predefinita è nessun controllo di runtime.)
  • analyze: esegue l’analisi del codice MSVC su tutto il codice nvdaHelper, bloccando ogni avviso. (l’impostazione predefinita è nessuna analisi).

Le parole chiave speciali none e all possono anche essere usate al posto dei singoli flag.

Segue un esempio che abilita i controlli di debug CRT e runtype

scons source nvdaHelperDebugFlags=debugCRT,RTC

I file pdb dei simboli sono sempre prodotti durante la costruzione, indipendentemente dai flag di debug.Tuttavia, non sono inclusi nella distribuzione di NVDA.Invece, scons symbolsArchive li impacchetterà come un archivio separato.

Per impostazione predefinita, la compilazione non utilizza alcuna ottimizzazione del compilatore.Si veda l’argomento della parola chiave release per quali ottimizzazioni del compilatore abilita.

Eseguire il codice sorgente

È possibile eseguire NVDA direttamente dai sorgenti senza dover costruire l’intero pacchetto binario e il launcher.Per lanciare NVDA dai sorgenti, usando cmd.exe, eseguire runnvda.bat nella root del repository.

Per visualizzare la guida sugli argomenti che NVDA accetta, usare l’opzione -h o --help.Questi argomenti sono anche documentati nella guida utente.

Costruire NVDA

Una build binaria di NVDA può essere eseguita su un sistema senza Python e tutte le altre dipendenze di NVDA installate (come facciamo per le istantanee e le release).

Archivi e bundle binari possono essere creati usando scons dalla root della distribuzione dei sorgenti di NVDA. Per creare uno dei seguenti elementi, aprire un prompt dei comandi e passare a questa directory.

Per fare una build binaria non archiviata (equivalente a un archivio portatile estratto), digitare:

scons dist

La build verrà creata nella directory dist.

Costruire l’installatore

Per creare un archivio di lancio (un eseguibile che permette l’installazione o la generazione di dist portatili), digita:

scons launcher

L’archivio sarà collocato nella directory di output.

Costruire la documentazione per gli sviluppatori

Per generare la guida per gli sviluppatori di NVDA, digita:

scons developerGuide

La guida per gli sviluppatori sarà collocata nella cartella devDocs della directory di output.

Per generare la documentazione del codice sorgente basata su HTML, digita:

scons devDocs

La documentazione sarà collocata nella cartella NVDA della directory di output.

Per generare la documentazione dello sviluppatore per nvdaHelper (non inclusa nell’obiettivo devDocs):

scons devDocs_nvdaHelper

La documentazione sarà posta nella cartella devDocs\nvdaHelper nella directory di output.

Genera archivio simboli di debug

Per generare un archivio di simboli di debug per i vari binari dll/exe, digita:

scons symbolsArchive

L’archivio sarà posto nella directory di output.

Genera template di traduzione

Per generare un template di traduzione gettext (per i traduttori), digitare:

scons pot

Personalizzazione della build

Opzionalmente, la build può essere personalizzata fornendo variabili sulla linea di comando:

  • version: La versione di questa build.
  • release: Se questa è una versione di rilascio.
    • Questo abilita varie ottimizzazioni del compilatore C++ come /O2 e l’ottimizzazione dell’intero programma.
    • Istruisce anche Python a generare codice byte ottimizzato.
  • publisher: L’editore di questa build.
  • certFile: Il file del certificato con cui firmare gli eseguibili. Il certificato deve essere in formato pfx e contenere la chiave privata.
  • certPassword: La password per la chiave privata nel certificato di firma. Se omesso, non verrà assunta alcuna password.
  • certTimestampServer: L’URL del server di timestamp da usare per timbrare le firme authenticode. Se omesso, le firme non saranno timestampate.
  • outputDir: La directory dove saranno collocati gli archivi finali costruiti e simili.
  • targetArchitectures: Le architetture di destinazione che NVDA dovrebbe supportare. I valori possibili sono all, x86 e x86_64. Questo dovrebbe essere generalmente lasciato come valore predefinito.

Per esempio, per costruire un lanciatore con una versione specifica, si potrebbe digitare:

scons launcher version=test1

Per ulteriori informazioni vedere il file sconstruct.

Esecuzione di test automatici

Se si apporta una modifica al codice di NVDA, si dovrebbero eseguire i test automatici di NVDA.

Per eseguire i test (test delle unità, controlli delle stringhe traducibili), per prima cosa cambiare directory alla radice della distribuzione dei sorgenti di NVDA come sopra.Poi, eseguire:

scons tests

Test delle unità

Per eseguire solo specifici test delle unità, specificarli usando la variabile unitTests sulla riga di comando.I test devono essere forniti come elenco separato da virgole.Ogni test deve essere specificato come modulo, classe o metodo Python relativo alla directory tests\unit.Per esempio, per eseguire solo i metodi nelle classi TestMove e TestSelection nel file tests\unit\test_cursorManager.py, eseguire questo comando:

scons tests unitTests=test_cursorManager.TestMove,test_cursorManager.TestSelection

Controlli delle stringhe traducibili

Per eseguire solo i controlli delle stringhe traducibili (che controllano che tutte le stringhe traducibili abbiano commenti del traduttore), eseguire:

scons checkPot

Linting delle tue modifiche

Per assicurarti che le tue modifiche siano conformi allo stile di codifica di NVDA puoi eseguire localmente il linter di Flake8.Alcuni sviluppatori hanno trovato fuorvianti alcuni messaggi di errore di linting, questi sono chiariti in tests/lint/readme.md.runlint.bat userà Flake8 per ispezionare solo le differenze tra la tua directory di lavoro e il ramo specificato base.Se crei una Pull Request, il ramo base che usi qui dovrebbe essere lo stesso che useresti per una Pull Request. Nella maggior parte dei casi sarà origin/master.

runlint origin/master

Per essere avvisati degli errori di linting più velocemente, potresti voler integrare Flake8 altri strumenti di sviluppo che stai usando.Per maggiori dettagli, vedi tests/lint/readme.md

Test unitari

I test unitari possono essere eseguiti con lo script rununittests.bat.Internamente questo script usa il framework di test Nose Python per eseguire i test.Qualsiasi argomento dato a rununittests.bat sono inoltrati a Nose.Si prega di fare riferimento alla documentazione di Nose su come filtrare i test ecc.

Test di sistema

I test di sistema possono essere eseguiti con lo script runsystemtests.bat.Internamente questo script usa il framework di test Robot per eseguire i test.Qualsiasi argomento dato a runsystemtests.bat è inoltrato a Robot.Per maggiori dettagli (incluso il filtraggio e l’esclusione dei test) vedi tests/system/readme.md.

Contribuire a NVDA

Se vuoi contribuire al codice o alla documentazione di NVDA, puoi leggere maggiori informazioni nella nostra guida al contributo.