NVDA (NonVisual Desktop Access) é um leitor de ecrã gratuito e de código aberto para Microsoft Windows. É desenvolvido pela NV Access em colaboração com uma comunidade global de colaboradores. Para saber mais sobre a NVDA ou fazer o download de uma cópia, visite o site principal da NV Access.
Nota de favor: o projecto NVDA tem um Código de Conduta de Cidadão e Contribuinte. O NV Access espera que todos os colaboradores e outros membros da comunidade leiam e cumpram as regras estabelecidas neste documento enquanto participam ou contribuem para este projeto.
- Obter suporte
- Documentação
- Canais de comunicação
- Outros links chave do projeto
- Obtendo o código fonte
- Dependências
- Dependências instaladas
- Submódulos Git
- Dependências Python
- Preparando a árvore de código fonte
- Compilando o NVDAHelper com Opções de Depuração
- Executando o código fonte
- Construindo NVDA
- Construir o instalador
- Construindo a documentação do desenvolvedor
- Gerar arquivo de símbolos de debug
- Gerar modelo de tradução
- Personalizar a compilação
- Executando Testes Automatizados
- Testes unitários
- Strings traduzíveis
- Imprimir as suas alterações
- Unit Tests
- Testes de sistema
- Contribuir para a NVDA
Obter suporte
Se você é um iniciante, um usuário avançado, um novo ou um desenvolvedor de longa data, ou se você é uma organização disposta a saber mais ou a contribuir com a NVDA, você pode obter suporte através da documentação em vigor, bem como vários canais de comunicação dedicados ao leitor de tela NVDA. Aqui está uma visão geral das fontes de suporte mais importantes.
Documentação
- NVDA Guia do Usuário
- NVDA Guia do Desenvolvedor
- NVDA Add-ons Estagiários de Desenvolvimento
- NVDA ControllerClient manual
- Outra documentação está incluída no Wiki deste repositório e no Wiki da Comunidade
Canais de comunicação
- NVDA Users Mailing List
- NVDA Developers Mailing List
- NVDA Add-ons Mailing List
- Canal de mensagens instantâneas para suporte a NVDA
- Outras fontes incluindo grupos e perfis em canais de mídia social, sites e listas de correio específicos do idioma, etc.
>
Você também pode obter suporte direto do NV Access. Veja o website NV Access para mais detalhes.
Outros links chave do projeto
- NVDA no GitHub
- Problemas NVDA no GitHub: Relatórios de bugs, pedidos de recursos, etc.
- Snapshots de desenvolvimento NVDA: builds gerados automaticamente do projeto em seu estado atual de desenvolvimento
- add-ons NVDA: Obter add-ons para melhorar NVDA
- Coordenação e centro de suporte de add-ons NVDA: tudo sobre o ambiente de add-ons NVDA
- Template de add-ons NVDA: Um repositório para gerar o modelo de add-ons
- Traduzindo NVDA: Informações sobre como traduzir NVDA para outro idioma
- Cliente Controlador NVDA (2010-02-19): NVDA API para aplicativos externos para falar diretamente ou mensagens em braile, etc.
- Contribuir com a NVDA: Diretrizes para contribuir com o código fonte NVDA
- Lista de e-mails de commits NVDA: Notificações para todos os commits para o repositório Git
- Arquivos de e-mail antigos: contêm discussões sobre o desenvolvimento de NVDA
Obtendo o código fonte
O projeto NVDA usa o sistema de controle de versão Git para seu código fonte e documentação.
O repositório NVDA Git está localizado em https://github.com/nvaccess/nvda.git. Você pode cloná-lo com o seguinte comando, que irá colocar os arquivos em um diretório chamado nvda
:
git clone --recursive https://github.com/nvaccess/nvda.git
A opção --recursive
é necessária para recuperar vários submódulos Git que usamos.
Dependências
O fonte NVDA depende de vários outros pacotes para rodar corretamente.
Dependências instaladas
As seguintes dependências precisam ser instaladas no seu sistema:
- Python, versão 3.8, 32 bit
- Utilizar a última versão menor se possível.
- Microsoft Visual Studio 2019 Community, Versão 16.3 ou posterior:
- Download from https://visualstudio.microsoft.com/vs/
- Quando instalar o Visual Studio, você precisa habilitar o seguinte:
- Na aba Workloads
- no grupo Windows:
- Desktop desenvolvimento com C++
- >Então, na seção Detalhes de instalação, em Desktop para C++, Agrupamento opcional, certifique-se de que o seguinte esteja selecionado:
- MSVC v142 – VS 2019 C+++ x64/x86 build tools
- Windows 10 SDK (10.0.19041.0)
- C++ ATL para ferramentas de construção v142 (x86 & x64)
- C++ Ferramentas de Clang para Windows
- no grupo Windows:
- Na guia Componentes individuais, certifique-se de que os seguintes itens estão selecionados:
- MSVC v142 – VS 2019 C+++ ARM64 build tools
- C++ ATL para v142 build tools (ARM64)
- Na aba Workloads
Submódulos Git
Algumas das dependências estão contidas nos submódulos Git.Se você não passou a opção --recursive
para clone de Git, você precisará executar git submodule update --init
.Sempre que um submódulo necessário cometer alterações (por exemplo, após o git pull), você precisará executar git submodule update
.Se você não tiver certeza, execute git submodule update
após cada git pull, merge ou checkout.
Para referência, as seguintes dependências de tempo de execução estão incluídas nos submódulos Git:
- eSpeak NG, versão 1.51-dev commit 53915bf0a
- Sonic, commit 4f8c1d11
- IAccessible2, commit cbc1f29631780
- liblouis, versão 3.17.0
- Unicode Common Locale Data Repository (CLDR), versão 38.1
- NVDA images and sounds
- Adobe Acrobat accessibility interface, versão XI
- MinHook, tagged version 1.2.2
- brlapi Python bindings, versão 0.8 ou posterior, distribuída com BRLTTTY para Windows, versão 6.1
- lilli.dll, versão 2.1.0.0
- Interface Python para driver/chip FTDI
- Java Access Bridge 32 bit, da Comunidade Zulu OpenJDK build 13.0.1+10Zulu (13.28.11)
Adicionalmente, as seguintes dependências de tempo de compilação estão incluídas no submódulo miscDeps git:
- txt2tags, versão 2.5
- Nulsoft Install System, versão 2.51
- NSIS UAC plug-in, versão 0.2.4, ansi
- xgettext e msgfmt do GNU gettext
- Boost Optional (stand-alone header), do commit 3922965
As seguintes dependências não são necessárias pela maioria das pessoas, e não estão incluídas nos submódulos Git:
-
Gerar documentação do desenvolvedor para o nvdaHelper: Doxygen Windows installer, versão 1.8.15:
-
Quando você estiver usando Visual Studio Code como seu ambiente de desenvolvimento integrado de preferência, você pode fazer uso da nossa configuração de espaço de trabalho pré-povoado para Visual Studio Code.Embora este projeto VSCode não esteja incluído como um submódulo no repositório NVDA, você pode facilmente verificar a configuração do espaço de trabalho em seu repositório executando o seguinte a partir da raiz do repositório.
git clone https://github.com/nvaccess/vscode-nvda.git .vscode
Dependências Python
NVDA e seu sistema de compilação também dependem de uma extensa lista de pacotes Python. Todos eles estão listados com suas versões específicas em um arquivo requirements.txt na raiz deste repositório. No entanto, o sistema de compilação toma conta de ir buscá-los quando necessário. estes pacotes serão instalados em um ambiente virtual Python isolado dentro deste repositório, e não afetarão seu conjunto de pacotes em todo o sistema.
Preparando a árvore de código fonte
Antes de poder executar o código fonte NVDA, você deve preparar a árvore de código fonte. Você faz isso abrindo um prompt de comando, mudando para a raiz da distribuição de código fonte NVDA e digitando:
scons source
Você deve fazer isso novamente sempre que a versão dos comtypes mudar ou arquivos de idioma forem adicionados ou alterados.Note que se você quiser acessar a documentação do usuário a partir do menu de ajuda enquanto executa a versão fonte, você também precisará adicionar user_docs
à linha de comando assim:
scons source user_docs
Embora simplesmente testar ou submeter as alterações, pode ser mais rápido geralmente apenas fazendo scons source
pois a documentação do usuário mudará cada vez que o número da revisão for alterado.
Compilando o NVDAHelper com Opções de Depuração
Em outras coisas, preparando a árvore de código fonte constrói as bibliotecas NVDAHelper. Se tentando depurar o nvdaHelper, você pode controlar várias opções de depuração construindo com as variáveis nvdaHelperDebugFlags
e nvdaHelperLogLevel
de linha de comando.
A variável nvdaHelperLogLevel
especifica o nível de registro (0-59) que você deseja ver, mais baixo é mais verboso. O padrão é 15.
A variável nvdaHelperDebugFlags
leva uma ou mais das seguintes flags:
- debugCRT: as bibliotecas serão ligadas contra o tempo de execução do debug C e as asserções serão habilitadas. (Por padrão, o CRT normal é usado e as asserções são desabilitadas.)
- RTC: verificações em tempo de execução (corrupção da pilha, variáveis não inicializadas, etc.) serão habilitadas. (O padrão é sem verificações em tempo de execução.)
- analisar: executa a análise do código MSVC em todo o código nvdaHelper, mantendo qualquer alerta. (o padrão não é análise).
As palavras-chave especiais none e all também podem ser usadas no lugar dos flags individuais.
A seguir um exemplo que permite verificações de debug CRT e runtype
scons source nvdaHelperDebugFlags=debugCRT,RTC
Symbol pdb arquivos são sempre produzidos ao construir, independentemente dos flags debug.No entanto, eles não estão incluídos na distribuição NVDA. Ao invés disso, scons symbolsArchive
irá empacotá-los como um arquivo separado.
Por padrão, as compilações também não usam nenhuma otimização do compilador. Por favor, veja o argumento de release
palavra-chave para quais otimizações de compilação ele irá habilitar.
Executando o código fonte
É possível executar NVDA diretamente do código fonte sem ter que compilar o pacote binário completo e o lançador.Para executar NVDA a partir do código fonte, usando cmd.exe
, execute runnvda.bat
na raiz do repositório.
Para ver a ajuda sobre os argumentos que NVDA aceitará, use a opção -h
ou --help
.Estes argumentos também estão documentados no guia do usuário.
Construindo NVDA
Uma compilação binária de NVDA pode ser executada em um sistema sem Python e todas as outras dependências de NVDA instaladas (como fazemos para snapshots e releases).
Arquivos e pacotes binários podem ser criados usando scons a partir da raiz da distribuição de fontes NVDA. Para compilar qualquer uma das seguintes opções, abra um prompt de comando e mude para este diretório.
Para fazer uma compilação binária não arquivada (equivalente a um arquivo portátil extraído), digite:
scons dist
A compilação será criada no diretório dist.
Construir o instalador
Para criar um arquivo lançador (um executável permitindo a instalação ou geração dist portátil), digite:
scons launcher
O arquivo será colocado no diretório de saída.
Construindo a documentação do desenvolvedor
Para gerar o guia do desenvolvedor NVDA, digite:
scons developerGuide
O guia do desenvolvedor será colocado na pasta devDocs
do diretório de saída.
Para gerar a documentação do código-fonte baseado em HTML, digite:
scons devDocs
A documentação será colocada na pasta NVDA
do diretório de saída.
Para gerar a documentação do desenvolvedor para nvdaHelper (não incluída no alvo devDocs):
scons devDocs_nvdaHelper
A documentação será colocada na pasta devDocs\nvdaHelper
no diretório de saída.
Gerar arquivo de símbolos de debug
Para gerar um arquivo de símbolos de debug para os vários binários dll/exe, digite:
scons symbolsArchive
O arquivo será colocado no diretório de saída.
Gerar modelo de tradução
Para gerar um modelo de tradução gettext (para tradutores), digite:
scons pot
Personalizar a compilação
Opcionalmente, a compilação pode ser personalizada fornecendo variáveis na linha de comando:
- versão: A versão deste build.
- release: Se esta é uma versão de lançamento.
- >
- Esta permite várias otimizações do compilador C++ tais como /O2 e otimização do programa inteiro.
- Também instrui Python a gerar código de byte otimizado.
- publisher: O editor deste build.
- certFile: O arquivo de certificado com o qual assinar os executáveis. O certificado deve estar no formato pfx e conter a chave privada.
- certPassword: A senha para a chave privada no certificado de assinatura. Se omitida, nenhuma senha será assumida.
- certTimestampServer: O URL do servidor de timestamp a ser usado para timestamp das assinaturas de autentificação. Se omitido, as assinaturas não serão timestamped.
- outputDir: O diretório onde os arquivos finais construídos e tais serão colocados.
- targetArchitectures: As arquiteturas alvo que a NVDA deve suportar. Os valores possíveis são todos, x86 e x86_64. Isto geralmente deve ser deixado como padrão.
Por exemplo, para construir um lançador com uma versão específica, você pode digitar:
scons launcher version=test1
Para mais veja o arquivo sconstruct
Executando Testes Automatizados
Se você fizer uma alteração no código NVDA, você deve executar os testes automatizados da NVDA. Estes testes ajudam a garantir que as alterações de código não quebram involuntariamente a funcionalidade que estava funcionando anteriormente.
Para executar os testes (testes unitários, verificações de strings traduzíveis), primeiro mude o diretório para a raiz da distribuição de código fonte NVDA como acima. Depois, execute:
scons tests
Testes unitários
Para executar somente testes unitários específicos, especifique-os usando a variável unitTests
na linha de comando.Por exemplo, para executar apenas métodos nas classes TestMove
e TestSelection
no arquivo tests\unit\test_cursorManager.py
, execute este comando:
scons tests unitTests=test_cursorManager.TestMove,test_cursorManager.TestSelection
Strings traduzíveis
Para executar apenas as verificações de strings traduzíveis (que verificam se todas as strings traduzíveis têm comentários do tradutor), execute:
scons checkPot
Imprimir as suas alterações
Para garantir que as suas alterações estejam de acordo com o estilo de codificação da NVDA você pode executar o linter Flake8 localmente.Alguns desenvolvedores encontraram certas mensagens de erro de impressão enganadoras, estas são esclarecidas em tests/lint/readme.md
.runlint.bat usará o Flake8 para inspecionar apenas as diferenças entre o seu diretório de trabalho e o ramo especificado base
. Se você criar um Pull Request, o ramo base
que você usa aqui deve ser o mesmo que o alvo que você usaria para um Pull Request. Na maioria dos casos será origin/master
.
runlint origin/master
Para ser avisado sobre erros de impressão mais rapidamente, você pode desejar integrar o Flake8 outras ferramentas de desenvolvimento que você está usando. Para mais detalhes, veja tests/lint/readme.md
Unit Tests
Unit tests podem ser executados com o script rununittests.bat
. Internamente este script usa o Nose Python test framework para executar os testes.Por favor consulte a documentação do próprio Nose sobre como filtrar testes etc.
Testes de sistema
Testes de sistema podem ser executados com o script runsystemtests.bat
. Internamente este script usa o framework de testes do Robot para executar os testes. Quaisquer argumentos dados a runsystemtests.bat são encaminhados para o Robot.Para mais detalhes (incluindo filtragem e exclusão de testes) veja tests/system/readme.md
.
Contribuir para a NVDA
Se você gostaria de contribuir com código ou documentação para a NVDA, você pode ler mais informações no nosso guia de contribuição.