Godot: Adicionar acessibilidade para desenvolvedores cegos que usam leitores de tela

Isso definitivamente seria uma melhoria bem-vinda, mas já posso dizer que provavelmente levará um tempo para ser implementado, se for o caso. O editor do Godot usa seu próprio kit de ferramentas GUI, que é o mesmo usado em jogos, e é totalmente independente dos kits de ferramentas nativos ou multiplataforma como Qt ou GTK+, que teriam um bom suporte para leitores de tela.

Então, para que isso funcione no Godot, teria que ser implementado do zero nos controles principais. Eu não sei o quão difícil isso é, mas provavelmente não é trivial.

Eu realmente pensei sobre isso, mas não sei nem por onde começar. O editor Godot é muito visual, você faz praticamente tudo com o mouse. Precisaríamos de uma pessoa com deficiência visual para nos dar consultoria sobre isso e nos orientar nessa tarefa, nos orientando sobre o que é realmente necessário e como deve se comportar. Sem um usuário real para fornecer feedback, é principalmente um jogo de adivinhação para implementar isso.

Eu ficaria feliz em orientá-los a adicionar isso. Eu mesmo sou cego. :) Pelo menos, eu poderia indicar a vocês frameworks (MSAA e UIA vêm à mente como possibilidades, embora UIA seja preferível para mim pelo menos, já que o NVDA (https://github.com/nvaccess/nvda) (um código aberto leitor de tela) o usa) e teste-o à medida que vocês avançam. Enquanto isso, existe um editor Godot alternativo ou método de criar o jogo à mão, sem o editor?

Se esse recurso for implementado no núcleo do próprio mecanismo, seria possível aos desenvolvedores fazer aplicativos para pessoas cegas, não apenas permitir que desenvolvedores cegos trabalhassem.
+1 para a proposta

Fico feliz em ver que isso está sendo analisado e a única coisa que tenho a acrescentar sobre isso é que o software de leitura de tela também é usado por pessoas com deficiências/dificuldades de aprendizado, como dislexia. Por mais que eu odeie a maneira como essas coisas às vezes deixam as pessoas de fora, acho que pode-se argumentar que isso amplia o caso para tal desenvolvimento.

O NV Access (NVDA) seria um bom primeiro lugar para entrar em contato, pois ambos os desenvolvedores principais são cegos e, portanto, têm uma visão adequada do que é necessário. Talvez um esforço colaborativo?

Oi,

Eu acho que isso vai ser um grande esforço. Isso pode ser feito, mas considerando os protocolos de acessibilidade nativos, uma implementação feita do zero pode ser muito problemática para usuários de todas as plataformas.

Se você planeja avançar com isso, recomendo que você use o modelo QT, uma camada de evento de acessibilidade abstrata em cima dos controles básicos da interface do usuário primeiro e uma implementação dependente da plataforma.

Outra abordagem é usar o Text To Speech diretamente. Isso pode ser mais independente da plataforma e muito fácil de trabalhar. Existem alguns problemas com isso também, mas eles estão mais relacionados ao mecanismo do que ao ambiente de tempo de execução.

Espero que isso possa ajudá-lo deside.

Saúde,

Esse modelo também funcionaria, se entrar em contato com a acessibilidade de baixo nível
As APIs falharam de alguma forma. Concordo 100 por cento que o NVAccess seria
sua melhor aposta para obter o mais alto nível de acessibilidade. :)

Em 18/05/18, Francisco R. Del Roio [email protected] escreveu:

Oi,

Eu acho que isso vai ser um grande esforço. Isso pode ser feito, mas considerando
protocolos de acessibilidade nativos uma implementação feita do zero pode ser
muito problemático para usuários de todas as plataformas.

Se você planeja avançar com isso, recomendo que você use o modelo QT,
uma camada de evento de acessibilidade abstrata em cima dos controles básicos da interface do usuário primeiro
e uma implementação dependente da plataforma.

Outra abordagem é usar o Text To Speech diretamente. Isso pode ser mais
independente de plataforma e muito fácil de trabalhar. Existem alguns problemas
com isso também, mas eles estão mais relacionados ao motor do que ao tempo de execução
ambiente.

Espero que isso possa ajudá-lo deside.

Saúde,

--
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -390176511

--
Assinado,
Ethin D. Probst

Como solução parcial, existem documentos, ou mesmo lugares para procurar, para implementar um jogo manualmente sem usar o editor? Eu vi os documentos da linha de comando, mas estou querendo saber se é mesmo prático/remotamente agradável trabalhar com os gráficos de cena e afins manualmente, eliminando completamente a necessidade do editor.

Como um exemplo mais prático, agora estou implementando um jogo tipo Asteroids baseado em áudio. Os asteróides emitem sons para marcar suas posições, e o jogador os centraliza no campo de áudio girando/voando ao redor. Eu não me importo particularmente com os visuais, mas eles seriam úteis para fins de depuração, então posso perguntar a pessoas com visão se, digamos, meu conceito mental da orientação da minha nave combina com os cilindros/esferas brutos que estou usando para depuração/ detecção de colisão. Eu estou querendo saber se é mesmo remotamente possível posicionar uma esfera de 5 unidades de diâmetro em 0,0, posicionar aleatoriamente e mover um monte de esferas de 25 unidades de diâmetro, implementar o comportamento de encapsulamento, etc. a necessidade do editor Godot. Ou será uma bagunça de edição de XML não amigável para humanos?

No momento estou fazendo isso mais ou menos à mão no Rust com um ECS. Isso não é terrível, mas me pergunto se ganho alguma coisa aproveitando um mecanismo de jogo real. Idealmente, a coisa de Asteroids é apenas uma prova de conceito, e eu eventualmente gostaria de fazer jogos de áudio mais ricos sem ter que construir tudo isso manualmente. Se Godot é essa solução, não sei...

De qualquer forma, acho que implementar uma interface de acessibilidade completa para o kit de ferramentas de interface do usuário provavelmente é pedir muito. Se os arquivos de dados são principalmente texto, mas não são amigáveis ​​para humanos, uma solução intermediária pode ser uma DSL que expõe uma interface simplificada para os tipos de tarefas que descrevi acima (posicionar primitivas de forma, anexar sons, adicionar lógica a entidades etc.)

Como solução parcial, existem documentos, ou mesmo lugares para procurar, para implementar um jogo manualmente sem usar o editor?

Eu acho que a maneira mais fácil (sem hackear) seria gerar as cenas processualmente via script. Você pode fazer isso em tempo de execução ou criar um script que salve as cenas e os recursos em disco para poder adicionar ao projeto. O scaffolding inicial exigiria um arquivo project.godot para as configurações do projeto (que pode ser um arquivo vazio feito pelo sistema operacional no início) e uma cena principal que é executada no início (que também pode ser definida e salva via script) . Pode ser complexo de gerenciar, mas é possível.

Tecnicamente, você pode fazer um script que seja executado diretamente da linha de comando e esse script faz todo o projeto Godot para você (pelo menos não consigo pensar em nada que impeça isso). Você também pode executar e exportar o jogo a partir da linha de comando. Você precisaria abrir o projeto no editor pelo menos uma vez para importar os ativos (e toda vez que os ativos mudarem), mas isso poderia ser resolvido executando a versão headless do Godot, como algumas pessoas estão fazendo para uso com servidores de Integração Contínua.

Se os arquivos de dados são principalmente texto, mas não são amigáveis ​​para humanos, uma solução intermediária pode ser uma DSL que expõe uma interface simplificada para os tipos de tarefas que descrevi acima (posicionar primitivas de forma, anexar sons, adicionar lógica a entidades etc.)

O formato de recurso de texto não é muito difícil de ler, mas ainda assim é provavelmente mais simples usar GDScript para criar coisas para o projeto, já que você pode usar o mecanismo básico para escrever e ler o formato (evitando problemas de compatibilidade).

Infelizmente, o GDScript não é a melhor linguagem para deficientes visuais, pois o espaço em branco é importante. Ouvi reclamações de um desenvolvedor cego sobre Python por causa disso.

Francamente, acho que as reclamações sobre a colocação de espaços em branco são
muito provavelmente (desculpe minha linguagem) ganhando mal-intencionado. Espaço em branco é
perfeitamente bem (sou cego e sou capaz de trabalhar com python muito bem,
assim como outras linguagens orientadas a espaços em branco, como F# e outras).
Aqueles que reclamam de espaços em branco são geralmente aqueles que são
desanimado com o pensamento de programação (o que aumenta a
questão de exatamente por que eles estão verificando em primeiro lugar) ou
aqueles que nem tentaram e que só reclamam por reclamar.
Eu não quero ser tão inflamatório, mas isso realmente me irrita quando eu
ver as pessoas reclamando disso. Simplesmente não faz absolutamente nenhum sentido.
Nunca ouvi falar da versão sem cabeça do Godot. Talvez isso pudesse
ser usado para criar projetos e interagir com o motor também? que
pode ser uma solução completa para nossos problemas no momento. Onde pode
eu acho essa versão? (Ou está no pacote Godot?)

Em 24/05/18, George Marques [email protected] escreveu:

Como solução parcial, existem documentos, ou mesmo lugares para procurar, para
implementar um jogo manualmente sem usar o editor?

Eu acho que a maneira mais fácil (sem hackear) seria gerar o
cenas processualmente via script. Você pode fazer isso em tempo de execução ou fazer
um script que salva as cenas e recursos em disco para que você possa adicionar ao
projeto. O andaime inicial exigiria um arquivo project.godot para
as configurações do projeto (que pode ser um arquivo vazio feito pelo sistema operacional em primeiro lugar)
e uma cena principal que é executada no início (que também pode ser configurada e salva via
roteiro). Pode ser complexo de gerenciar, mas é possível.

Tecnicamente, você pode fazer um script que seja executado diretamente da linha de comando
e esse script faz todo o projeto Godot para você (pelo menos não consigo
pense em qualquer coisa que impeça isso). Você pode então executar e exportar o
jogo a partir da linha de comando também. Você precisaria abrir o projeto em
editor pelo menos uma vez para importar os assets (e toda vez que os assets
mudança), mas isso pode ser resolvido executando a versão sem cabeça do Godot,
como algumas pessoas estão fazendo para uso com servidores de Integração Contínua.

Se os arquivos de dados são principalmente texto, mas não amigáveis, um meio-termo
solução pode ser uma DSL que expõe uma interface simplificada para os tipos
de tarefas que descrevi acima (posicionar primitivas de forma, anexar
sons, adicionando lógica às entidades. etc.)

O formato do recurso de texto não é muito difícil de ler, mas ainda é provavelmente
mais simples usar GDScript para criar coisas para o projeto, já que você pode
usar o motor base para escrever e ler o formato (evitando
problemas de compatibilidade).

Infelizmente, GDScript não é a melhor linguagem para deficientes visuais
pessoas, uma vez que o espaço em branco é importante. Eu ouvi reclamações de um cego
desenvolvedor sobre Python por causa disso.

--
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -391900905

--
Assinado,
Ethin D. Probst

@ethindp Não vou discutir sobre o que é ou não é, já que não sou cego, mas vou pedir para você diminuir o tom. As pessoas têm origens diferentes e podem ter motivos adequados para achar difícil trabalhar, enquanto você aprendeu a trabalhar com isso. A pessoa que conheço trabalha como desenvolvedor para viver, acho difícil acreditar que ele "não se esforçou o suficiente" (ainda é de segunda mão para mim, então não vou discutir sobre isso).

Nunca ouvi falar da versão sem cabeça do Godot. Talvez isso pudesse
ser usado para criar projetos e interagir com o motor também? que
pode ser uma solução completa para nossos problemas no momento. Onde pode
eu acho essa versão? (Ou está no pacote Godot?)

Ela é chamada de plataforma server e funciona apenas no Linux. Ele não é distribuído (talvez seja assim que o 3.1 for lançado), então você precisa compilar para acessá-lo. Este é apenas o mecanismo Godot normal, mas possui drivers fictícios para vídeo para não exigir uma placa gráfica.

Não tenho certeza do quanto você pode interagir com ele, provavelmente não pode fazê-lo manualmente. Ainda assim, ele pode ser usado para executar scripts e importar ativos, então é possível fazer um projeto com ele se você fizer tudo com scripts (pelo menos em teoria).

Vou repetir o que @ethindp diz que o recuo não deve ser um problema. A maioria dos leitores de tela modernos tem configurações para falar a indentação automaticamente (ou seja, "8 espaços def hello_world():`, e eu conheço muitos desenvolvedores Python cegos e prolíficos.

Gostaria de saber se existe ainda outra solução intermediária - uma ferramenta de linha de comando orientada por linha que pode manipular o gráfico de cena em tempo real, conduzir outra instância e permitir que você salve sua saída. Estou pensando em um estilo de interação como:

$ godot-shell mygame.godot
Welcome to the Godot shell.

> new entity
Entity created with ID 0.
> add component 0 position
Component "position" added with ID 0.0.
> set component 0.0 [0, 0]
Component 0.0 set.
> save
Scene graph saved.
>

Estou, então, imaginando uma instância separada rodando em outra janela, exibindo o que o motor está produzindo atualmente, tocando sons, etc. Outros comandos podem gerar um editor de texto GUI para editar scripts.

Esse tipo de fluxo de trabalho faria sentido se o objetivo fosse criar um jogo mais simplista? Ou seja, eu realmente não me importo com a aparência dos meus modelos de jogador/mundo, além de serem formas simples para que eu possa modelá-los mentalmente, anexar sons e ter um sistema de detecção de colisão que faça algum sentido. Eu também acho que uma CLI é um pouco mais fácil de prototipar e experimentar do que uma DSL completa.

Eu posso começar a hackear isso se as pessoas que sabem mais do que eu sobre Godot acharem que é viável. Estou procurando um bom problema de interface CLI para afundar meus dentes e tenho algumas bibliotecas Rust que gostaria de testar. O formato do arquivo/dados está documentado em algum lugar?

@George Marques, peço desculpas pelo meu comportamento rude...
do meu peito. Porque realmente me irrita e parece ganhar
mais do que uma verdade real, sabe?
@Nolan Darilek, sua ideia pode ter mérito; seria possivel codificar
uma interface de interface do usuário alternativa, talvez usando algo como WXWidgets?
Se usássemos o WX, ele resolveria todos os nossos problemas de acessibilidade de uma só vez.
(Pessoalmente, eu nunca consegui descobrir totalmente o WX ....
muito complexo para mim .... heh :)).

Em 25/05/18, Nolan Darilek [email protected] escreveu:

Vou repetir o que @ethindp diz que o recuo não deve ser um problema. A maioria
leitores de tela modernos têm configurações para falar o recuo automaticamente (ou seja,
"8 espaços def hello_world():`, e eu conheço muitos Python cegos prolíficos
desenvolvedores.

Gostaria de saber se existe ainda outra solução de meio-termo - uma linha orientada
ferramenta de linha de comando que pode manipular o gráfico de cena em tempo real,
outra instância e permitir que você salve sua saída. estou pensando em um
estilo de interação como:

$ godot-shell mygame.godot
Welcome to the Godot shell.

> new entity
Entity created with ID 0.
> add component 0 position
Component "position" added with ID 0.0.
> set component 0.0 [0, 0]
Component 0.0 set.
> save
Scene graph saved.
>

Estou imaginando uma instância separada em execução em outra janela, exibindo
o que quer que o motor esteja produzindo atualmente, reproduzindo sons, etc. Outros
comandos podem gerar um editor de texto GUI para editar scripts.

Esse tipo de fluxo de trabalho faria sentido se o objetivo é criar um
jogo simplista? Ou seja, eu realmente não me importo com a aparência dos meus modelos de jogador/mundo
tipo, além de serem formas simples para que eu possa modelá-las mentalmente, anexar
sons, então temos um sistema de detecção de colisão que faz algum tipo de
senso. Eu também acho que uma CLI é um pouco mais fácil de prototipar e experimentar
do que é um DSL completo.

Eu posso começar a hackear isso se as pessoas que sabem mais do que eu sobre Godot
acho viável. Procurando um bom problema de interface CLI para afundar meu
dentes, e tenho algumas bibliotecas Rust que eu gostaria de colocar em seus
passos. O formato do arquivo/dados está documentado em algum lugar?

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -392111005

--
Assinado,
Ethin D. Probst

Da mesma forma re: WX. Se eu fosse fazer uma GUI, provavelmente iria com GTK
já que estou no Linux, mas nunca sentei para aprender GTK ou WX, e isso
pareceria uma variável demais para brincar aqui.

Eu acho que inicialmente começaria com uma CLI que pode iniciar/parar uma renderização
Godot processa e conduz esta versão sem cabeça. Se eu fiz isso em Rust,
Eu provavelmente construiria uma implementação struct e serde para um subconjunto do
formato que a interface suportaria. Com isso como ponto de partida,
deve ser fácil construir uma GUI mais tarde ou em paralelo.

Isso funcionaria, sim; mas como exatamente você vai fazer isso em
ferrugem? Acho que ferrugem seria perfeito para isso, mas pelo que vi,
o editor do motor, pelo menos, é escrito em C++. Na verdade, parece que o
núcleo também é. Assim, uma vez que (segundo
https://doc.rust-lang.org/beta/nomicon/ffi.html) Rust não pode fazer interface
com C++, precisaríamos criar uma interface C. Isso em si seria
um pesadelo absoluto. :)

Em 25/05/18, Nolan Darilek [email protected] escreveu:

Da mesma forma re: WX. Se eu fosse fazer uma GUI, provavelmente iria com GTK
já que estou no Linux, mas nunca sentei para aprender GTK ou WX, e isso
pareceria uma variável demais para brincar aqui.

Eu acho que inicialmente começaria com uma CLI que pode iniciar/parar uma renderização
Godot processa e conduz esta versão sem cabeça. Se eu fiz isso em Rust,
Eu provavelmente construiria uma implementação struct e serde para um subconjunto do
formato que a interface suportaria. Com isso como ponto de partida,
deve ser fácil construir uma GUI mais tarde ou em paralelo.

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -392121156

--
Assinado,
Ethin D. Probst

Eu estava pensando em editar os arquivos diretamente, o que parece mais factível se
você expõe uma interface mais limitada que cresce ao longo do tempo (ou seja, inicialmente
exponha apenas formas básicas, corpos rígidos, sons, etc., em seguida, adicione mais
tempo.) Estou olhando para o formato e parece ser principalmente INI, ou seja:

[node name="WallContainer" type="Node" parent="." index="0"]

editor/display_folded = true

Embora eu não soubesse que os nomes das seções poderiam ser de forma tão livre. :) EU
acho que não há nada na especificação INI, tal que é, para evitar isso.

Então, como um MVP, eu gostaria:

* Corpos 2-D dinâmicos/estáticos rígidos para detecção de colisão e movimento
* Algumas primitivas básicas de forma para modelar mentalmente os corpos e
representá-los na tela para feedback visual. Cilindros para caracteres,
esferas e algum tipo de polígono em blocos para paredes/terras deve ser
suficiente por agora.
* Áudio espacial
* Áudio não espacial para sons de música/UI
* Acesso a scripts e a capacidade de adicionar comportamentos de script a qualquer
dos acima que o suportam

Eu não quero chamar isso de pequena façanha, mas se eu pudesse descobrir o
nós necessários para implementar esse conjunto de recursos e, em seguida, criar um usuário de texto
interface para construir essa estrutura e, em seguida, chamar o Godot
ferramentas para exportação/renderização, podemos estar em algo. Há muitos
de tipos de nós, mas se eles estiverem documentados em qualquer tipo de
maneira legível por máquina, pode ser possível eventualmente tocar em algum tipo
do gerador de código Rust ou escreva uma macro para replicar a mesma interface do usuário pt
mas é melhor descobrir como essa interface do usuário se parece antes
alcançando uma macro para gerá-la automaticamente. :)

Se eu estiver certo sobre tudo ser baseado em INI, eu poderia montar um
MVP PoC para ver onde isso vai dar. Para ser claro, não estou visando um
caso de uso de editor de uso geral aqui, apenas uma maneira de criar jogos de áudio
sem necessariamente codificar tudo à mão, e alavancar um
motor de jogo real para fazer a exportação de plataforma cruzada.

Mas por mais divertido que seja esse brainstorming, tenho que trabalhar e terminar
a semana. Vou colocar um repo em breve e ver onde ele vai. eu
geralmente prefiro o GitLab por causa de seu CI integrado, mas eu poderia estar
convencido a permanecer no GitHub se as pessoas se opuserem.

O formato do arquivo é descrito (pelo menos parcialmente) na documentação: http://docs.godotengine.org/en/latest/development/file_formats/tscn.html

No entanto, fazer uma ferramenta completamente nova para isso é muito trabalhoso e tende a se tornar obsoleto com bastante facilidade. Pelo menos você deve usar GDNative como uma ponte (que é uma interface C para o mecanismo C++), que daria acesso a todas as informações sobre classes e suas propriedades. Por mais que eu aprecie o esforço, acho que primeiro você precisa entender um pouco o que Godot tem a oferecer, para não reinventar todas as rodas.

Se você realmente quer fazer com Rust, você pode tentar as ligações para GDNative (embora eu não possa atestar sua estabilidade): https://github.com/GodotNativeTools/godot-rust

Pessoalmente, eu tentaria fazer algo com o próprio núcleo Godot (talvez como um módulo C++), já que você pode acessar toda a API facilmente, incluindo todos os protetores e carregadores de recursos, para que você não precise se preocupar com formatos de arquivo .

Se você optar por uma interface CLI, ela deve ser baseada na organização da árvore de cenas, que é a parte mais importante de qualquer jogo Godot. Projetar esse processo de antemão é provavelmente mais importante: criar uma maneira fácil de entender como a árvore é disposta e as ferramentas para mover os nós para uma posição específica da árvore devem ser a base do projeto. Se você conseguir isso, nem precisa limitar o conjunto de recursos, já que praticamente qualquer coisa pode ser feita com a árvore.

Depois disso, você precisa de uma maneira de definir as propriedades dos nós individuais, incluindo os recursos que são usados ​​para fornecer uma funcionalidade adequada (por exemplo, um nó CollisionShape2D precisa de um recurso Shape2D para dar sua forma). Scripts também são recursos, então eles também podem ser configurados por meio dessa interface (embora você possa querer dar a eles um status especial). Isso substituiria o que o Inspetor está na GUI.

Além disso, eu faria os comandos o mais próximo possível do GDScript. Por exemplo, você quer criar um Sprite, você pode simplesmente fazer Sprite.new() , que é o mesmo que você faria em um script. Dessa forma, a curva de aprendizado para alguém já acostumado com scripts seria menos íngreme.

Para áudio, Godot usa players e ônibus. Existem players para áudio posicional (tanto 2D quanto 3D) e um regular para áudio não posicional, que também são todos nós na árvore. Surround também é suportado (embora eu nunca o tenha usado). Para trabalhar com os barramentos, você precisa interagir com o AudioServer, definir o volume, silenciá-los ou solá-los e adicionar efeitos. Você pode usar o recurso AudioBusLayout diretamente, mas não tenho certeza de quanto dele está exposto à API externa. Os efeitos são apenas recursos, portanto podem ser editados pela mesma interface.

Tudo isso na minha humilde opinião, é claro. Eu uso Godot há muito tempo, então posso ser um pouco tendencioso.

Ei, obrigado, isso é útil. Eu não sou particularmente casado com bagunça
com os arquivos de dados diretamente. Feliz em saber como isso pode
trabalho - a maioria dos documentos de introdução que encontro ensinam construindo
jogos, e ninguém assume que você precisaria construir suas próprias ferramentas primeiro. :)

Eu não toquei em C++ em quase 2 décadas, então provavelmente vou ficar com
Enferruja e lide com uma API menos completa ou problemas de arquivo se eu atingir algum
instabilidade. O gdnative suporta projeto de leitura/escrita, cena e
outros arquivos diretamente? Ou destina-se a apoiar a escrita de jogos em C e
ligando no motor? Eu fiz um breve grep através do repositório Rust para
"projeto" e não encontrou nada. Os exemplos parecem centrados
construindo jogos diretamente. Se você não se importar em me dar um ponto de entrada para
onde eu começaria a construir um projeto e preenchê-lo programaticamente, eu
leia sobre isso e mova outros trabalhos para meu próprio repositório.

Obrigado mais uma vez por me agradar. :)

O GDNative destina-se a fazer jogos, essencialmente substituindo scripts. Mas como eu disse antes, você pode fazer praticamente qualquer coisa com scripts, e o GDNative usa a mesma API.

Oi,

Para cenas ou objetos semelhantes e complexos, você pode usar um formato como este arquivo .

Neste caso, é apenas para um mapa para um projeto chamado audioquake, mas pode ser um exemplo. PD: Não tente construir isso, pode não funcionar.

Para GUI, você também pode usar o QT5.11, vi que inclui muitas melhorias para acessibilidade. Nesse caso, você só precisará adicionar algum tipo de suporte de acessibilidade para controles personalizados rígidos, como a câmera.

Saúde,

O formato para mapas de terremotos de áudio é muito limitado. Eu pessoalmente não gosto.

Em 25/05/18, Francisco R. Del Roio [email protected] escreveu:

Oi,

Para cenas ou objetos semelhantes e complexos, você pode usar um formato como este
arquivo .

Neste caso, é apenas para um mapa para um projeto chamado audioquake, mas
pode ser um exemplo. PD: Não tente construir isso, pode não funcionar.

Para GUI, você também pode usar o QT5.11, vi que inclui muitas melhorias
para acessibilidade. Neste caso, você só precisará adicionar algum tipo de
suporte de acessibilidade para controles personalizados rígidos, como a câmera.

Saúde,

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -392214077

--
Assinado,
Ethin D. Probst

Espere, estou sendo um idiota. Você disse no início deste tópico que
você não precisava do editor, exceto ao importar ativos. eu
acho que teria sido mais correto para mim perguntar se eu precisava do
GUI para criar jogos. Estou feliz em executá-los a partir da GUI, só quero
para desenvolvê-los no console. E parece que posso.

Então eu acho que o que eu quero é uma série "Godot do zero" que assuma você
não pode/não quer usar o editor, semelhante a como você faria
escrevendo um jogo com pygame ou outra biblioteca de alto nível. eu imagino uma vez
Eu descobri como criar um arquivo .project que apenas inicia um
script, e talvez um script que apenas abre uma janela e gira um cubo ou
alguma coisa, eu posso aplicar isso para cima. Eu duvido que tal coisa exista, então
talvez eu tente eu mesmo e blog o processo. Então talvez eu construa um
Ferramenta de prototipagem CLI mais tarde, quando eu souber o que posso querer prototipar
sem código.

Você sabe... eu me pergunto se nós podemos de alguma forma fazer o motor não apenas um
engine com um editor e tal, mas uma biblioteca também? Tipo, seu dado
as bibliotecas C++ (libs estáticas ou dinâmicas) e pode construir seu jogo
como quiser, usando Godot para todas as coisas do motor de jogo (ou seja,
áudio e tal). Se isso fosse possível, poderíamos renunciar ao editor
inteiramente. Assim, você pode adicionar ativos como, digamos, arquivos .caf e, em seguida, em
runtime, você os compilaria na memória como arquivos de dados de ativos compilados (nós
poderia apenas chamá-los de CADFs). Então seu jogo ficaria assim, na inicialização:

//...
// Compilar ativos
godot::ativos::LoadAll({ativo, ativo, ativo}); // carrega cada ativo individualmente
ou
Godot::Assets::LoadAllAssetsFrom("assets"); // carrega todos os ativos em
uma vez de uma pasta.
// Compilar todos os ativos
ativos automáticos = Godot::Assets::GetAllLoadedAssets();
bool sucesso = Godot::Assets::Cadf::CompileAllAssets(assets);
se (sucesso) {
// ativos compilados
} senão {
// erro
}

Concedido, este é o meu estilo de codificação, e duvido que seja a forma como o
motor está escrito. Mas se fosse possível fazer isso, seria
épico. Ou podemos simplesmente renunciar à compilação de ativos, basta carregar todos
deles quando precisamos deles, ou todos eles na inicialização.

Em 25/05/18, Nolan Darilek [email protected] escreveu:

Espere, estou sendo um idiota. Você disse no início deste tópico que
você não precisava do editor, exceto ao importar ativos. eu
acho que teria sido mais correto para mim perguntar se eu precisava do
GUI para criar jogos. Estou feliz em executá-los a partir da GUI, só quero
para desenvolvê-los no console. E parece que posso.

Então eu acho que o que eu quero é uma série "Godot do zero" que assuma você
não pode/não quer usar o editor, semelhante a como você faria
escrevendo um jogo com pygame ou outra biblioteca de alto nível. eu imagino uma vez
Eu descobri como criar um arquivo .project que apenas inicia um
script, e talvez um script que apenas abre uma janela e gira um cubo ou
alguma coisa, eu posso aplicar isso para cima. Eu duvido que tal coisa exista, então
talvez eu tente eu mesmo e blog o processo. Então talvez eu construa um
Ferramenta de prototipagem CLI mais tarde, quando eu souber o que posso querer prototipar
sem código.

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -392224709

--
Assinado,
Ethin D. Probst

Acho que teria sido mais correto eu perguntar se eu precisava do
GUI para criar jogos. Estou feliz em executá-los a partir da GUI, só quero
para desenvolvê-los no console. E parece que posso.

Você não precisa de GUI para rodar jogos. Na verdade, o editor apenas cria outro processo Godot com os argumentos para rodar o jogo (com todas as opções de depuração também). Executar o jogo não é um problema: você pode simplesmente executar Godot do diretório do projeto sem argumentos, o padrão é executar o projeto.

O editor é praticamente um "jogo" Godot. Ele usa os nós disponíveis e os estende. A parte sobre importação, não é que você precise da GUI, você só precisa das ferramentas de importação que vêm com o editor. Essencialmente, você apenas coloca todos os ativos na pasta do projeto (em qualquer estrutura que desejar) e quando você abre o editor, ele importa tudo.

"Importar" neste caso significa armazenar metadados (se você quiser fazer um loop e cortar o áudio, ou aplicar filtro a uma imagem, etc.) e às vezes converter para um formato que Godot entenda e possa usar (como importar um modelo para uma malha Godot ). O processo de importação só pode ser feito pelo build das ferramentas (ou seja, o editor), mesmo que seja a versão headless.

Quando você exporta o jogo, apenas os ativos importados são empacotados, os originais são ignorados. Para o jogo em si, esse processo é transparente: você pode tratar os ativos como se estivessem no local original, os carregadores saberão obter a versão importada.

Assim como o editor é apenas um jogo, você pode fazer seu próprio "jogo" que na verdade é uma ferramenta para fazer jogos. Quer dizer, você pode até criar um script que estenda MainLoop ou SceneTree e execute diretamente via terminal com:

$ godot -s my_script.gd

O problema é que você quer uma verdadeira ferramenta CLI, Godot não vai facilitar. Mesmo executando um script ele abrirá uma janela, e tudo que for enviado via stdin será ignorado.

Gostaria de saber se podemos de alguma forma fazer o motor não apenas um
engine com um editor e tal, mas uma biblioteca também? Tipo, seu dado
as bibliotecas C++ (libs estáticas ou dinâmicas) e pode construir seu jogo
como quiser, usando Godot para todas as coisas do motor de jogo (ou seja,
áudio e tal).

Embora o editor e a engine sejam feitos um para o outro, você não depende inteiramente do editor para fazer o jogo. Você não pode dividir Godot em pedaços, você precisa pegar o pacote inteiro (embora você possa desabilitar a maioria dos módulos sem problemas). Como o editor é um jogo Godot, é tecnicamente possível substituir o código pelo seu próprio jogo. Isso significaria criar as cenas em tempo real com código.

Godot não deve ser usado como uma biblioteca ou estrutura, e provavelmente nunca será, mas você pode hackear e fazer uma implementação MainLoop que nem mesmo usa nós, em vez disso, basta chamar os servidores diretamente. Claro, você precisaria construir o mecanismo a partir da fonte, mas imagino que essa seja a menor das preocupações.

Tudo isso é tecnicamente possível, e talvez não seja tão difícil, mas é se aventurar em território desconhecido.

Desculpe por ser barulhento, pessoal.

Então, desde então, mergulhei bastante em Godot e li muitos
a documentação. Normalmente eu não faço isso para uma ferramenta que não seja de biblioteca como
isso porque é meio que um longo caminho em direção ao desejado
resultado - basicamente construindo todas as ferramentas em sua marcenaria
antes de poder cortar uma única folha de compensado. :)

Estou lentamente chegando à visão de que o próprio editor pode ser
acessível através da construção de um mini leitor de tela em
GDScript. Isso tem o benefício adicional de tornar as próprias UIs do jogo
acessível. Também não é sem precedentes. Ver
isto
para um plug-in de acessibilidade da interface do usuário do Unity.

Ao olhar para a classe Control , parece haver sinais expostos
para o foco entrar/sair. Existem também sinais para eventos de entrada, que eu
esperança inclui setas em torno de campos de entrada de texto e similares. Seria
limitado para um leitor de tela genérico no nível do sistema operacional, mas pode funcionar para
algo específico do domínio.

eu comecei em algo
aqui . Infelizmente,
Não consigo adicionar este plugin ao meu projeto porque preciso do inacessível
editor para adicionar o plugin de acessibilidade. :) Se alguém pudesse adicionar isso
plugin para o projeto e envie um PR com as alterações project.godot,
isso seria útil. Essencialmente, o que vou fazer é ligar o
node_added (ou como é chamado) sinal em SceneTree , interceptar
quaisquer nós que desçam de Control e se conectem a seus
focus_entered sinal. Uma vez lá, começarei a adicionar lógica para imprimir
mensagens de apresentação para cada tipo de nó que eventualmente será canalizado
para uma API TTS ainda não escrita. Por favor, deixe-me saber se há algum
razões óbvias pelas quais isso não funcionaria.

E como eu faria isso um plugin sem editor que funcionaria com qualquer
Godot UI, incluindo aqueles em jogos sem editor?

Espero que possamos eventualmente mover a discussão para este outro repositório e parar
spam este problema. :)

Se entendi bem, se isso funcionasse, poderíamos optar por
incluí-lo em nossos jogos ou não, certo? Existe alguma maneira de adicionar
para o editor, mas não para os projetos que criamos, ou para removê-lo
do projeto, mas adicioná-lo ao editor?

Em 26/05/18, Nolan Darilek [email protected] escreveu:

Desculpe por ser barulhento, pessoal.

Então, desde então, mergulhei bastante em Godot e li muitos
a documentação. Normalmente eu não faço isso para uma ferramenta que não seja de biblioteca como
isso porque é meio que um longo caminho em direção ao desejado
resultado - basicamente construindo todas as ferramentas em sua marcenaria
antes de poder cortar uma única folha de compensado. :)

Estou lentamente chegando à visão de que o próprio editor pode ser
acessível através da construção de um mini leitor de tela em
GDScript. Isso tem o benefício adicional de tornar as próprias UIs do jogo
acessível. Também não é sem precedentes. Ver
isto
para um plug-in de acessibilidade da interface do usuário do Unity.

Ao olhar para a classe Control , parece haver sinais expostos
para o foco entrar/sair. Existem também sinais para eventos de entrada, que eu
esperança inclui setas em torno de campos de entrada de texto e similares. Seria
limitado para um leitor de tela genérico no nível do sistema operacional, mas pode funcionar para
algo específico do domínio.

eu comecei em algo
aqui . Infelizmente,
Não consigo adicionar este plugin ao meu projeto porque preciso do inacessível
editor para adicionar o plugin de acessibilidade. :) Se alguém pudesse adicionar isso
plugin para o projeto e envie um PR com as alterações project.godot,
isso seria útil. Essencialmente, o que vou fazer é ligar o
node_added (ou como é chamado) sinal em SceneTree , interceptar
quaisquer nós que desçam de Control e se conectem a seus
focus_entered sinal. Uma vez lá, começarei a adicionar lógica para imprimir
mensagens de apresentação para cada tipo de nó que eventualmente será canalizado
para uma API TTS ainda não escrita. Por favor, deixe-me saber se há algum
razões óbvias pelas quais isso não funcionaria.

E como eu faria isso um plugin sem editor que funcionaria com qualquer
Godot UI, incluindo aqueles em jogos sem editor?

Espero que possamos eventualmente mover a discussão para este outro repositório e parar
spam este problema. :)

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -392255752

--
Assinado,
Ethin D. Probst

Eu não sei.

Eu descobri o formato para adicionar um plugin ao project.godot
Arquivo. Agora eu tenho uma função que deveria estar adicionando
focus_entered/mouse_entered para cada Control e imprime um
mensagem quando eles têm foco. Infelizmente não estou conseguindo
nenhum desses eventos, nem tenho certeza de como obter o nó real que
os originou.

Nada nisto é específico do editor, no entanto, e deve automaticamente
detectar a adição de qualquer controle de interface do usuário em qualquer lugar na árvore de cena e,
eventualmente, implemente um leitor de tela para ele.

OK, aqui é onde estou depois de alguns hackers intermitentes de fim de semana de feriado:

1. Repositório movido
   aqui . eu ia
   prefiro trabalhar com a identidade da minha potencial empresa de desenvolvimento de jogos,
   mas lançarei o plugin sob a licença do MIT se for
   em qualquer lugar, então a colaboração é bem-vinda.
2. Em teoria, estou gerando classes com código específico de acessibilidade
   sempre que um Controle é adicionado à árvore.
3. Foi informado no IRC que o comportamento tab/shift-tab já está definido no
   UI, mas quando o editor é iniciado, nada tem foco, então tab/shift-tab
   não faça nada até que algo fique em foco.
4. Estou tentando definir um foco inicial, e parece que estou fazendo isso com
   algum widget LineEdit aleatório, mas tab/shift-tab não parece mover o
   foco. Isso pode ser porque eles estão sendo capturados pelo controle LineEdit.
5. Definir um foco inicial para qualquer outra coisa não parece funcionar - em
   pelo menos, não de acordo com meu retorno de chamada focus_entered .

Estou tendo dificuldades com isso porque sou novo no motor, mas estou
vindo de uma direção que a maioria dos novatos não toma. :) Se
alguém pode me ajudar a desvendar esse quebra-cabeça de foco inicial, acho que posso fazer
muitos progressos rápidos. Uma vez que eu possa usar tab/shift-tab para navegar entre
controles, posso ver quais propriedades cada uma expõe e começar a criar
uma apresentação acessível para eles. Também fico feliz em registrar problemas
contra o próprio mecanismo - eu simplesmente não sei quais comportamentos específicos
peça ainda.

Obrigado.

Você provavelmente precisa definir o focus_mode do Controle. Acredito que o padrão é não aceitar o foco, exceto os que precisam (como controles de texto e botão). Você também pode precisar definir os vizinhos de foco, não tenho certeza de quão bem o TAB funciona sem ele (ou se funciona).

Obrigado. Acabei de começar a hackear com FOCUS_MODE_ALL. Com isso, eu
pode chamar grab_focus em itens anteriormente sem foco.

Em relação aos vizinhos, li em
http://docs.godotengine.org/en/3.0/classes/class_control.html :

Se o usuário pressionar Tab, Godot dará foco ao nó mais próximo
para a direita primeiro, depois para baixo. Se o usuário pressionar Shift+Tab,
Godot olhará para a esquerda do nó, depois acima dele.

Isso é exatamente o que eu implementaria se eu fizesse isso sozinho, então parece
o padrão é perfeito.

Se você tiver um momento, você poderia, por favor, acionar o editor em um novo
projeto, talvez um com um project.godot vazio apenas para manter as coisas
semelhante e veja em que condições a tab/shift-tab funciona no editor?
Acho que a pessoa que ajudou a testar as coisas no IRC pode ter criado seu
próprio layout, enquanto o que eu quero fazer é testar as coisas diretamente no
editor. Se tab/shift-tab não funcionar, então eu tenho um bug específico para arquivar.
A crença atual sob a qual estou operando é que eles não funcionam
inicialmente, mas depois que um item é clicado.

E, curiosamente, quando acompanho focus_exited, recebo um evento
quando eu pressiono tab. Infelizmente, nunca recebo outro focus_entered, então
uma vez que meu foco deixa um controle, ele nunca retorna a um.

Obrigado pela ajuda.

http://docs.godotengine.org/en/3.0/classes/class_nodepath.html#class-nodepath

Se você tiver um momento, você poderia, por favor, acionar o editor em um novo
projeto, talvez um com um project.godot vazio apenas para manter as coisas
semelhante e veja em que condições a tab/shift-tab funciona no editor?

Tab não faz nada na primeira abertura. Se eu clicar em algum lugar para dar foco, ele começa a circular pelos controles, mas não parece que todos estão focados. As abas dos containers dock não parecem estar focadas, o que significa que algumas partes da interface não podem ser acessadas apenas via teclado.

Obrigado. Esse problema está ficando um pouco fora de controle. vou arquivar
outro sobre ideias de brainstorming em torno do foco do editor.

Não tenho certeza do que fazer, arquivei #19230, mas não houve muita atividade. Também postei no fórum e fui aconselhado a registrar um problema. Pensamentos sobre onde pedir ajuda a seguir? Não consigo ver se meu complemento está realmente definindo o foco, se Tab/Shift-tab o move ou não, por que recebo um evento focus_exited em cada pressionamento de tecla, mesmo que não seja uma tecla de navegação. Não quero ser chato, mas sinto que poderia progredir bastante contribuindo com 10 minutos de ajuda de um desenvolvedor Godot experiente. Pensei em cutucar esse problema e aumentar o número 19230, que tem uma lista de perguntas mais focada (sem trocadilhos).

Obrigado.

Só queria que as pessoas soubessem que este repositório está progredindo rapidamente. Eu posso agora:

• tab/shift-tab ao redor do editor, obtendo feedback sobre qual controle tem foco. Atualmente tem apresentação semi-inteligente de Button e LineEdit . Mais para vir em breve.
• Seta para a esquerda/direita nos controles do LineEdit, obtendo feedback sobre qual personagem está em foco. Suporte adicional do LineEdit virá assim que eu ver a rapidez com que os PRs são tratados. Acabei de enviar um adicionando um sinal caret_moved .

Ajuda bem-vinda, embora esteja ciente de que este complemento agora requer uma versão do Godot com PRs não mesclados. Especificamente, consulte https://gitlab.com/lightsoutgames/godot-accessibility/issues/1 para obter uma lista de verificação de todos os PRs enviados e seu status de mesclagem.

Se você gostaria de ajudar, mas não quer pisar em nenhum pé, uma ótima maneira de fazer isso seria construir um módulo TTS. No momento, este complemento apenas imprime no console. O que eu gostaria é uma API como esta:

TTS.speak("hello, world.", interrupt = True)
TTS.stop() # Interrupts speech if in progress
TTS.rate = 200 # We'd need to coordinate some sort of rate algorithm between engines.

Qualquer coisa mais complicada, como vozes, pode esperar para depois. Se alguém quiser ajudar e criar essa API, provavelmente posso fazê-la funcionar no Linux e no Android. Caso contrário, chegarei a isso eventualmente, embora o leitor de tela tenha prioridade para mim.

Se você puder me dizer como implementa novas APIs GDScript, posso
implemente isso para o Windows, pelo menos.

Em 12/06/18, Nolan Darilek [email protected] escreveu:

Só queria que as pessoas soubessem que issorepositório está fazendo
Progresso rápido. Eu posso agora:

• tab/shift-tab ao redor do editor, obtendo feedback sobre qual controle
  foco. Atualmente tem apresentação semi-inteligente de Button e
  LineEdit . Mais para vir em breve.
• Seta para a esquerda/direita nos controles LineEdit, obtendo feedback sobre quais
  personagem tem foco. Suporte adicional do LineEdit para vir assim que eu ver como
  rapidamente PRs são tratados. Acabei de enviar um adicionando um caret_moved
  sinal.

Ajuda bem-vinda, embora esteja ciente de que este complemento agora requer uma versão do
Godot com PRs não mesclados. Especificamente, consulte
https://gitlab.com/lightsoutgames/godot-accessibility/issues/1 para um
lista de verificação de todos os PRs enviados e seu status de mesclagem.

Se você gostaria de ajudar, mas não quer pisar em nenhum pé, uma ótima maneira de fazer
então seria construir um módulo TTS. No momento, este addon apenas imprime no
console. O que eu gostaria é uma API como esta:

TTS.speak("hello, world.", interrupt = True)
TTS.stop() # Interrupts speech if in progress
TTS.rate = 200 # We'd need to coordinate some sort of rate algorithm between
engines.

Qualquer coisa mais complicada, como vozes, pode esperar para depois. Se alguém quiser
para ajudar e criar tal API, provavelmente posso fazê-lo funcionar no Linux e
Android. Caso contrário, chegarei a isso eventualmente, embora o leitor de tela
tem prioridade para mim.

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -396575401

--
Assinado,
Ethin D. Probst

Eu não sei. Estou cego e aprendendo tudo isso também, então se estou aprendendo
como construir o módulo TTS então não estou construindo o leitor de tela
módulo. :) Eu vou aprender isso eventualmente, mas minhas mãos estão cheias
empurrando o GDScript o máximo que puder, depois ajustando o mecanismo quando não puder
obter algo do GDScript. Todo esse processo é muito parecido com quando
Comecei a construir meu leitor de tela Android. eu não sabia o que era
possível, comecei a hackear as coisas e só tive uma noção
pelo que eu estava fazendo há alguns meses.

E minha suposição é que você precisará do GDNative, a menos que o GDScript ofereça
algum tipo de FFI. Eu acho que você construiria um módulo C/C++ que chama o Windows'
APIs de fala e exporta as funções para GDScript. Então eu pegaria isso
módulo e fazê-lo funcionar em Linux/Android usando Speech-dispatcher e
TTS nativo do Android. Suponho que também poderia fazer web usando
API TTS do Javascript. Se o GDScript oferecer FFI para C/C++, faça
avise.

Obrigado!

Vou dar uma olhada e ver se consigo exportar algumas funções usando o Tolk
biblioteca para se comunicar com leitores de tela.

Em 12/06/18, Nolan Darilek [email protected] escreveu:

Eu não sei. Estou cego e aprendendo tudo isso também, então se estou aprendendo
como construir o módulo TTS então não estou construindo o leitor de tela
módulo. :) Eu vou aprender isso eventualmente, mas minhas mãos estão cheias
empurrando o GDScript o máximo que puder, depois ajustando o mecanismo quando não puder
obter algo do GDScript. Todo esse processo é muito parecido com quando
Comecei a construir meu leitor de tela Android. eu não sabia o que era
possível, comecei a hackear as coisas e só tive uma noção
pelo que eu estava fazendo há alguns meses.

E minha suposição é que você precisará do GDNative, a menos que o GDScript ofereça
algum tipo de FFI. Eu acho que você construiria um módulo C/C++ que chama o Windows'
APIs de fala e exporta as funções para GDScript. Então eu pegaria isso
módulo e fazê-lo funcionar em Linux/Android usando Speech-dispatcher e
TTS nativo do Android. Suponho que também poderia fazer web usando
API TTS do Javascript. Se o GDScript oferecer FFI para C/C++, faça
avise.

Obrigado!

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -396669298

--
Assinado,
Ethin D. Probst

Isso parece quase perfeito. Deixe-me saber se você tem um módulo GDNative
trabalhando para isso. Se não, vou implementar algo para Linux em um mês
ou assim, talvez.

Se você não quiser torná-lo um módulo (o que requer a recompilação de todo o mecanismo), a única maneira de acessar bibliotecas externas é usar GDNative. Você não pode fazer FFI com GDScript.

Vou apenas adicioná-lo às funções globais do GDScript. Essa multa?

Em 12/06/18, George Marques [email protected] escreveu:

Se você não quiser fazê-lo como um módulo (o que requer a recompilação do
todo o mecanismo), a única maneira de acessar bibliotecas externas é usar GDNative.
Você não pode fazer FFI com GDScript.

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -396736512

--
Assinado,
Ethin D. Probst

Acho que faria mais sentido como uma classe estática com membros. Ou seja:

TTS.speak("Hello, world", interrupt = True)
TTS.stop()

Isso, pelo menos, é como outros módulos parecem fazer isso.

Uma rápida pesquisa no Google revela um bom tutorial GDNative completo com um
projeto de amostra usando scons. Se você começar a partir daí, eu deveria ser capaz de
pegue isso e adicione suporte ao despachante de fala. Não tenho certeza de como alguém adiciona, digamos,
JS para fazer interface com a API WebSpeech, mas uma coisa de cada vez.

Bem merda. Eu já fiz o commit e fiz o upload para o meu fork do repo
como parte do GDScript. Se você visitar https://github.com/ethindp/godot,
você pode ver como eu fiz isso. Eu sei, eu fui fora da norma, mas Tolk,
mesmo em C/C++, não é uma biblioteca baseada em classes. Então agora (eu acho)
você pode invocá-lo assim:

tts_load()
tts_output("Hi", false);
tts_unload()

Para que isso funcione com um leitor de tela, você precisará de alguns
arquivos (junto com o leitor de tela):

• JAWS, Window Eyes, ZoomText, System Access: Nada, funciona através de COM.
• NVDA: NVDAControllerClient32.dll e NVDAControllerClient64.dll
  (https://www.dropbox.com/s/7txp6iyi65sx12z/nvdaControllerClient32.dll?dl=1
  e https://www.dropbox.com/s/y0pdyxhos31hv9n/nvdaControllerClient64.dll?dl=1)
• Leitores de tela Dolphin: Dolapi32.dll
  (https://www.dropbox.com/s/m04mpzi7z6bfu5i/dolapi32.dll?dl=1)
• API de fala da Microsoft (MSSAPI/SAPI): sapi32.dll e sapi64.dll
  (https://www.dropbox.com/s/7czg0rt9ht9yloq/SAAPI32.dll?dl=1 e
  https://www.dropbox.com/s/e2fxek89p6muz2h/SAAPI64.dll?dl=1)
  Alternativamente, você pode baixar todos eles aqui:
  https://www.dropbox.com/sh/aatj7myhczyxs5u/AAA6K5aAZWis9uAF4CsNz_-Za?dl=1.
  Não testei, apenas incorporei. Desculpe se isso foi ruim
  ideia ou não. :) Eu não tenho certeza de como vamos conseguir
  tts_speak/tts_output/tts_braille para funcionar, pois exigem um wchar_t.
  Isso exporta as seguintes funções:
  tts_load(): Inicializa o Tolk carregando e inicializando a tela
  drivers do leitor e configuração do driver do leitor de tela atual, fornecido
  pelo menos um dos leitores de tela suportados está ativo. Além disso
  inicializa COM se ainda não tiver sido inicializado na chamada
  fio. Chamar esta função mais de uma vez inicializará apenas COM.
  Você deve chamar esta função antes de usar as funções abaixo. Usar
  tts_is_loaded para determinar se o Tolk foi inicializado.
  tts_is_loaded(): Testa se o Tolk foi inicializado. Retorna verdadeiro se
  Tolk foi inicializado, caso contrário false.
  tts_unload(): Finaliza o Tolk finalizando e descarregando a tela
  drivers do leitor e limpar o driver do leitor de tela atual, desde
  um foi definido. Também não inicializa COM no thread de chamada. Ligando
  esta função mais de uma vez apenas desinicializar COM. Você deve
  não use as funções abaixo se esta função tiver sido chamada.
  tts_try_sapi(bool): Define se o Microsoft Speech API (SAPI) deve ser usado
  no processo de detecção automática do leitor de tela. O padrão é não
  incluem SAPI. O driver SAPI usará o sintetizador padrão do sistema,
  voz e placa de som. Esta função aciona o leitor de tela
  processo de detecção, se necessário. Para melhor desempenho, você deve chamar
  esta função antes de chamar tts_load(). Parâmetros: trySAPI: se
  ou não incluir SAPI na detecção automática.
  tts_prefer_sapi(bool): Se a detecção automática para SAPI foi ativada
  através de tts_try_sapi(), define se SAPI deve ser colocado primeiro (true) ou
  último (falso) na lista de detecção do leitor de tela. Colocar por último é
  o padrão e é bom para usar SAPI como uma opção de fallback. Colocando
  primeiro é bom para garantir que o SAPI seja usado mesmo quando um leitor de tela
  está em execução, mas lembre-se de que os leitores de tela ainda serão testados se
  SAPI não está disponível. Esta função aciona o leitor de tela
  processo de detecção, se necessário. Para melhor desempenho, você deve chamar
  esta função antes de chamar tts_load. Parâmetros: preferSAPI:
  se deve ou não preferir SAPI sobre drivers de leitor de tela em
  detecção automática.
  tts_detect_screen_reader(): Retorna o nome comum para o atual
  driver de leitor de tela ativo, se um estiver definido. Se nenhum estiver definido, tenta
  detectar o leitor de tela ativo no momento antes de procurar o nome.
  Se nenhum leitor de tela estiver ativo, NULL será retornado. Observe que os drivers
  codificar o nome comum, ele não é solicitado do leitor de tela
  em si. Você deve chamar tts_load uma vez antes de usar esta função.
  tts_has_speech(): Testa se o driver atual do leitor de tela suporta
  saída de voz, se uma estiver definida. Se nenhum estiver definido, tenta detectar o
  leitor de tela atualmente ativo antes de testar o suporte de fala. Você
  deve chamar tts_load uma vez antes de usar esta função.
  tts_has_braille(): Testa se o driver atual do leitor de tela suporta
  saída braille, se uma estiver definida. Se nenhum estiver definido, tenta detectar o
  leitor de tela atualmente ativo antes de testar o suporte a braille. Você
  deve chamar tts_load uma vez antes de usar esta função.
  tts_output(string, bool): Emite texto através da tela atual
  driver do leitor, se um estiver definido. Se nenhum estiver definido ou se encontrou um
  erro, tenta detectar o leitor de tela ativo no momento antes
  saída do texto. Esta é a função preferida para enviar
  texto para um leitor de tela, porque usa toda a saída suportada
  métodos (fala e/ou braille dependendo do leitor de tela atual
  motorista). Você deve chamar tts_load uma vez antes de usar esta função.
  Esta função é assíncrona. Parâmetros: str: texto para saída.
  interrupção: se deve ou não cancelar primeiro qualquer discurso anterior.
  tts_speak(string): Fala texto através do leitor de tela atual
  driver, se um estiver definido e oferecer suporte à saída de fala. Se nenhum estiver definido ou se
  encontrou um erro, tenta detectar a tela atualmente ativa
  leitor antes de falar o texto. Use esta função somente se você
  especificamente precisa falar o texto através do leitor de tela atual
  sem também brailá-lo. Nem todos os drivers de leitor de tela podem suportar
  esta funcionalidade. Portanto, use tts_output sempre que possível. Você
  deve chamar tts_load uma vez antes de usar esta função. Esta função é
  assíncrono. Parâmetros: str: texto para falar. interrupção: se ou
  para não cancelar primeiro qualquer discurso anterior.
  tts_braille(string): texto Braille através do leitor de tela atual
  driver, se um estiver definido e suportar saída em braille. Se nenhum estiver definido ou
  se encontrou um erro, tenta detectar o atualmente ativo
  leitor de tela antes de escrever o texto em brail. Use esta função apenas
  se você precisar especificamente de texto em braille na tela atual
  leitor sem também falar. Nem todos os drivers de leitor de tela podem
  suportar esta funcionalidade. Portanto, use tts_output sempre que
  possível. Você deve chamar tts_load uma vez antes de usar esta função.
  Parâmetros: str: texto para braille.
  tts_is_speaking(): Testa se o leitor de tela associado ao
  driver do leitor de tela atual está falando, se um estiver definido e suportar
  consultando informações de status. Se nenhum estiver definido, tenta detectar o
  leitor de tela atualmente ativo antes de testar se está falando. Você
  deve chamar tts_load uma vez antes de usar esta função. Retorna verdadeiro se
  o texto está sendo falado pelo leitor de tela, caso contrário, false.
  tts_silence(): silencia o leitor de tela associado ao atual
  driver do leitor de tela, se um estiver definido e oferecer suporte à saída de fala. Se
  nenhum está definido ou se encontrou um erro, tenta detectar o
  leitor de tela atualmente ativo antes de silenciá-lo. Você deveria ligar
  tts_load uma vez antes de usar esta função. Retorna verdadeiro em caso de sucesso,
  falso caso contrário.
  Aproveitar! :)

Em 12/06/18, Nolan Darilek [email protected] escreveu:

Acho que faria mais sentido como uma classe estática com membros. Ou seja:

TTS.speak("Hello, world", interrupt = True)
TTS.stop()

Isso, pelo menos, é como outros módulos parecem fazer isso.

Uma rápida pesquisa no Google revela um bom tutorial GDNative completo com um
projeto de amostra usando scons. Se você começar a partir daí, eu deveria ser capaz de
pegue isso e adicione suporte ao despachante de fala. Não tenho certeza de como alguém adiciona, digamos,
JS para fazer interface com a API WebSpeech, mas uma coisa de cada vez.

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment-396753704

--
Assinado,
Ethin D. Probst

O próprio Tolk não precisa ser baseado em classe para exportar uma interface baseada em classe. Dê uma olhada no tutorial para um exemplo puro baseado em C de criação de uma classe GDScript. Primeiro hit no Google para "tutorial gdnative".

Não poderei usar isso porque já tenho um garfo de motor com sinal personalizado. Eu gostaria de evitar ajustar o mecanismo, a menos que seja necessário, e apenas nas maneiras mínimas necessárias para criar acessibilidade em complementos.

Bom começo, no entanto.

Ah, para o inferno com isso, eu só vou dar uma facada nisso. :) Exceto que é
vai estar em Rust, então é isso. Parece que há um Tolk Rust
vinculativo. Eu não posso fazer a porta do Windows, então você terá que preencher aqueles
em branco você mesmo.

Há uma encadernação de ferrugem Tolk? Onde? Não encontrei... vou procurar. :)

Em 12/06/18, Nolan Darilek [email protected] escreveu:

Ah, para o inferno com isso, eu só vou dar uma facada nisso. :) Exceto que é
vai estar em Rust, então é isso. Parece que há um Tolk Rust
vinculativo. Eu não posso fazer a porta do Windows, então você terá que preencher aqueles
em branco você mesmo.

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -396768693

--
Assinado,
Ethin D. Probst

É o primeiro hit ao pesquisar "tolk rust" para mim. Além disso,
aparece em cargo search tolk ..

Em todo caso, outra pergunta Godot. Se eu tiver um módulo GDNative que
expõe uma classe TTS ao GDScript, como faço para garantir que essa classe seja
disponível globalmente? Eu criei meu arquivo .gdnlib, mas o tutorial em
http://docs.godotengine.org/en/3.0/tutorials/plugins/gdnative/gdnative-c-example.html
apenas mostra um gráfico ao criar o arquivo .gdns. O que faz um .gdns
arquivo parecido para que eu possa criar um à mão? Parece que eu carrego a classe
via preload em vez de apenas disponibilizá-lo globalmente, é isso
preciso?

Obrigado.

se eu tiver um módulo GDNative que expõe uma classe TTS ao GDScript, como posso garantir que essa classe esteja disponível globalmente?

Talvez seja possível adicioná-lo como um singleton de carregamento automático. Na verdade, há um lugar para singletons GDNative no editor, então talvez haja uma maneira ainda melhor de criá-los. No entanto, não há documentação sobre isso e não tenho idéia de como funciona.

apenas mostra um gráfico ao criar o arquivo .gdns. O que faz um .gdns
arquivo parecido para que eu possa criar um à mão?

Depois de seguir as instruções, ele gera um arquivo como este:

[gd_resource type="NativeScript" load_steps=2 format=2]

[ext_resource path="res://bin/gdexample.gdnlib" type="GDNativeLibrary" id=1]

[resource]

resource_name = "gdexample"
class_name = "gdexample"
library = ExtResource( 1 )

Uma atualização:

Estou pensando em abandonar o projeto completamente ou bifurcar o motor. Como um pouco de contexto, passei 4-5 anos construindo Spiel, um leitor de tela Android bastante importante, durante um período em que as APIs de acessibilidade do Android não eram muito boas. Gosto de pensar que tenho algum conhecimento sobre o que faz uma boa API de acessibilidade e também sou sensível às necessidades de desempenho do sistema operacional subjacente e da experiência do usuário. Por fim, abandonei o projeto em grande parte porque era difícil construir sobre uma API de acessibilidade incompleta e tive que recorrer a hack após hack para tornar o Spiel útil.

Godot é mais ou menos assim. Na verdade, existem sinais de interface do usuário suficientes para uma API de acessibilidade razoavelmente sofisticada. Mas precisarei de mais alguns para que um complemento de acessibilidade tenha informações suficientes. Especificamente, #19522 teria facilitado as coisas, mas me pediram para refatorar isso em código específico do complemento. Agora #19814 também está sendo debatido. Eu entendo não querer adicionar um milhão de sinais, mas estou tentando ser sensível a isso. Todas as minhas alterações devem ficar confinadas à camada de interface do usuário, e não consigo imaginar isso tendo muito efeito, a menos que alguém esteja jogando um jogo de digitação em que todo o desempenho seja necessário para renderizar um EditLine em 120 FPS. :) Mesmo assim, o núcleo vai precisar de algumas adições se as pessoas realmente quiserem que isso aconteça.

E no final das contas eu só queria fazer jogos, então se eu tiver que defender rigorosamente cada PR sozinho sem muito apoio das pessoas que gostariam de ver isso acontecer, ou se eu estiver construindo todos os addons por mim mesmo, eu realmente não estou fazendo isso. Não tentando agitar as coisas, eu só queria deixar uma atualização aqui para inspirar algum tipo de discussão de processo sobre como podemos fazer isso acontecer se for realmente desejado, ou para deixar qualquer um que esteja pensando em fazer isso saber que pode haver alguns retrocesso.

Parece que o número 19840 pode ser discutido em uma próxima reunião de relações públicas. Se as pessoas realmente querem que Godot seja mais acessível, eu apreciaria mais defensores do que eu nessa reunião. Eu nem sei quando é essa reunião, ou se não vai entrar em conflito com reuniões de trabalho reais que eu preciso comparecer para $dayjobs. :) Estou percebendo que não posso fazer isso sozinho, e vou precisar de ajuda de qualquer parte interessada.

Obrigado.

@ndarilek Se você ainda estiver interessado em trabalhar nisso, gostaria de ajudar.

Eu sei que já faz um tempo, mas vou tentar pegar isso de novo. As pessoas recomendaram um grande conjunto de patches com todas as correções de acessibilidade necessárias para o mecanismo, então vou tentar e espero que ninguém me peça para dividi-lo. :)

Mas estou atingindo alguns limites em termos do que eu, como uma pessoa cega, posso fazer. No momento eu tenho uma interface de fala que me permite navegar pelo editor, interagir com menus, interagir/alterar algumas configurações do projeto, etc. tutoriais baseados, mas não desbloqueou o suficiente da interface. Alguém poderia responder o seguinte:

• Onde está a guia do mapa de entrada em Projeto -> Configurações do projeto? Eu vejo uma árvore de opções - config, run, editor, editor plugins, etc. mas nenhum mapa de entrada. Estou tentando obter uma lista de nomes de ação para que eu possa ver o que está disponível. Estou me perguntando se isso está em uma parte da interface que ainda não tornei acessível, embora esteja surpreso que não esteja na árvore de categorias.
• Posso acionar programaticamente uma ação? Em particular, alguns tutoriais me dizem para clicar com o botão direito do mouse em um nó, mas não vejo uma maneira de fazer isso no teclado. Eu gostaria de vincular a tecla Menu para clicar com o botão direito do mouse para que eu possa seguir algumas das etapas deste tutorial .
• Como alternativa, existe uma maneira amigável ao teclado de clicar com o botão direito do mouse e uma lista de atalhos de teclado em qualquer lugar? Talvez meu problema seja que o Menu funcione, mas não tenho acessibilidade suficiente do mecanismo exposta para saber disso.

E @malcolmhoward , se sua oferta de colaboração ainda estiver aberta um ano depois, estou desanimado. Estou disposto a dar mais uma chance. Vejo que você tentou mesclar algum suporte do Festival. Se você estiver interessado em continuar esse trabalho, tenho um plug-in TTS baseado em Rust que atualmente suporta Speech Dispatcher no Linux e Tolk no Windows. Adoraria diversificar esse suporte (e testar o suporte do Windows Tolk para esse assunto, já que o Linux é minha plataforma principal).

Obrigado.

Ignore minha primeira pergunta acima. Descobri e adicionei suporte acessível a TabContainer . Agora posso encontrar e selecionar a guia Mapa de entrada. Ainda um pouco confuso sobre se há uma maneira amigável do teclado para clicar com o botão direito do mouse na árvore da cena ou, se falhar, como posso acionar essa ação programaticamente.

O que seria muito útil seria se eu pudesse fazer uma chamada de compartilhamento de tela com alguém familiarizado com o desenvolvimento da Godot para me ajudar em algumas tarefas iniciais. Coisas que gostaria de realizar:

• Criando um campo de jogo vazio inicial.
• Criando um nó/cena do jogador e adicionando-o à área.
• Aprendendo a acessar as propriedades em cada nó/cena para que eu possa defini-las sem arrastar/soltar.
• Aprendendo a anexar scripts aos meus nós. Eu consegui o suficiente das configurações acessíveis que consegui definir meu editor externo para gedit, então, depois de descobrir como anexar um script a um nó e editar esse script, estou de volta ao meu editor acessível para essa tarefa.

Se eu pudesse fazer essas coisas, acho que poderia progredir muito mais rápido. Mesmo desenterrar problemas de acessibilidade executando qualquer um dos itens acima me ajudaria a concentrar meus esforços. No momento, estou apenas tentando, tentando encontrar coisas que não são acessíveis e fazê-las funcionar quando o que preciso fazer é focar em minhas tarefas e partir daí.

Obrigado.

@ndarilek Sim, eu ainda gostaria de ajudar a trabalhar isso. Vou precisar de mais ou menos uma semana para recuperar o equilíbrio com tudo relacionado a esse problema e, então, ficarei feliz em participar de uma ligação. Não sou especialista no motor, mas acho que construí protótipos de jogos suficientes para começarmos.

Eu meio que descobri como adicionar scripts. Resolvi começar a construir um
jogo simples ao lado do plugin de acessibilidade para que os colaboradores
têm um quadro de referência comum maior para discutir questões de acessibilidade.
Eu criei um nó Player Area2D, e muitas abas ao redor revelaram o
botão para adicionar um script, que abriu o Gedit e foi muito útil
experiência. Progresso!

Asteroids é uma espécie de meu objetivo para aprender um mecanismo ou estrutura, então
em seguida, pensei em adicionar uma cena principal para encapsular toda a lógica do jogo
que não poderia caber em um único tipo de entidade. Eu criei uma cena, defina
seu tipo de nó raiz para Node, e não consigo encontrar um
botão para adicionar um script. Não faço ideia se não é possível adicionar
um script para esta cena em particular por algum motivo, etc.

Eu instenciei um jogador como filho da cena e posso ver o jogador
e seu botão para limpar o script. Mas não tenho ideia de por que não posso adicionar um
script apenas para o nó raiz da cena principal.

Meu trabalho está aqui
para quem quiser acompanhar. Você também pode precisar do TTSplugin embora possa funcionar
sem ele também e apenas imprima erros sempre que tentar falar
algo. Mas de qualquer forma, remover o plug-in de acessibilidade
possivelmente revelar por que minha configuração de nó simples não está me deixando anexar um
script para Principal. Pode ser que eu não esteja selecionando corretamente a cena principal
na árvore, nesse caso é um feedback útil.

Além disso, é justo dizer que muitos desses botões no editor estão em
barras de ferramentas? Estou tentando encontrar um meio mais fácil de navegar
através de todos esses botões através do teclado, porque
tabulação/shift-tab através de todos eles é um pouco lento. Se muitos estão em
barras de ferramentas, posso implementar tabulação entre as barras de ferramentas e
seta para a direita/esquerda entre os componentes da barra de ferramentas.

O nó principal na árvore não é diferente dos outros nós até onde eu sei, exceto pelo fato de que ele é selecionado quando sua nova aba de cena é aberta pela primeira vez na criação.

OK, mais progresso. Eu expus mais propriedades em Tree ao discurso. eu
pensei que as setas para cima/para baixo estavam navegando dentro da árvore, mas eles
parecem estar selecionando itens. Eu acho que o que está acontecendo é que eu tenho
vários nós de cena selecionados, então o botão para adicionar um script não
aparecer. Eu posso colocar a árvore em um estado onde apenas um item é
selecionados expandindo/recolher itens, ponto em que o Add Script
botão aparece para Principal.

Alguém pode explicar a lógica para pressionar as setas para cima/para baixo em um
árvore? Eu assumi que navegou para um único item e selecionei o que quer que fosse
focado, mas em algo como uma árvore de cenas que suponho suporta
multi-select, eu estou querendo saber se ele se comporta de forma diferente? Tem alguma
pressionamento de tecla diferente para navegar em uma árvore e selecionar um único
item, ou há algo para desmarcar o item atual?

Obrigado.

Muito bom progresso ontem. O inspetor de propriedade tem alguns
coisas dobráveis ​​que não têm foco ou interatividade no teclado,
mas eu os desenterrei e fiz alguma magia negra com simulação de mouse
cliques, então agora posso expandir/recolher as propriedades do nó por meio do teclado.
As árvores são cerca de 80% acessíveis, embora as árvores multi-colunas com diferentes
controles ainda representam um desafio.

Falando nisso, estou confuso sobre como o editor de mapa de entrada funciona. Eu vejo uma
série de ações representadas por itens de árvore. A árvore tem 3 colunas: 0 =
ação, 1 = zona morta. Expandir cada tipo de ação parece expor
filhos para tipos de dispositivos, e suponho que daqui posso configurar
ações, mas estou confuso sobre muitas coisas:

* Qual é a terceira coluna não rotulada nesta árvore?

* Digamos que eu adicione uma ação, "speak_coordinates". Eu recebo um item de árvore para o
ação sem filhos. Como adiciono um filho para um mapeamento de teclas? Pode ser
tem a ver com alguma interação com esta terceira coluna não rotulada que
Ainda não estou dando suporte de forma acessível?

* O que é o TextureButton não rotulado nesta tela? Clicando nele
parece fechar as configurações, mas não é o botão "Fechar" rotulado, então
talvez seja outra ação? Salvar/Desfazer?

Obrigado por qualquer ajuda.

@ndarilek A terceira coluna do editor de mapa de entrada contém um botão para adicionar um novo evento de entrada a uma ação existente (ao lado das ações na árvore, é representado por um símbolo "mais"). Para eventos de entrada existentes, contém dois botões, um para editar o evento de entrada (o esquerdo, representado por uma caneta) e outro para removê-lo (o direito, representado por uma cruz).

O TextureButton que fecha as configurações é provavelmente o ícone de fechamento do WindowDialog (representado por uma cruz), é implementado aqui: https://github.com/godotengine/godot/blob/750f8d4926edb14269d9f6a117c5a9fd4765373a/scene/gui/dialogs.cpp#L338 - L345

As configurações do projeto são uma caixa de diálogo modal, daí o uso de WindowDialog.

Obrigado, isso é útil. Agora estou expondo a contagem de botões na coluna
anúncios de Tree e estou recebendo um anúncio do fato de que
existem botões.

Obrigado por me indicar onde está Close TextureButton
implementado - estou tendo dificuldade em rastrear alguns deles no
fonte, e estou tentando definir meta campos em alguns deles, então meu plugin
pode fornecer descrições/rótulos acessíveis.

Acabei de adicionar um método get_button_tooltip(...) a TreeItem para expor
dicas de ferramentas dos botões, já que os botões nas colunas só são retornados como
objetos Texture e não há como acessar a dica de ferramenta associada
através disso. Espero que não seja uma mesclagem questionável quando eu enviar uma
PR maior para este plugin.

Obrigado novamente.

Agora implementei um pouco de hacker que permite que você use a seta para a direita para um
coluna de botões em uma árvore, use Home/End para alternar entre eles e use
Espaço para ativar um. Através deste mecanismo, agora posso ativar a caixa de diálogo
para adicionar uma chave a uma ação criada.

Eu tenho uma pergunta sobre como isso funciona, porém, complicada pelo fato
que não posso usar o teclado para explorar esta caixa de diálogo. Ele intercepta
um único conjunto de teclas pressionadas, então deixe-me confirmar/cancelar isso? Ou faz isso
interceptar todas as chaves enviadas a ele e tornar a última chave o que é
em última análise, vinculado à ação?

Ou seja, eu adiciono uma ação, "speak_coordinates", que eu quero vincular
"c". Se esta caixa de diálogo aparecer e eu pressionar "c", tente tab para o
botão OK, faz isso:

a) vincular "c" à ação, ignorando pressionamentos de tecla subsequentes?

b) vincular "c", depois "tab" quando tento guiar para o botão OK?

Pensamentos bem-vindos sobre como lidar com esse caso extremo. Eu posso adicionar um meta
propriedade para esta caixa de diálogo específica informando o plug-in para apenas
suporte a captura do primeiro InputEvent ou, se isso já acontecer,
redirecionando o foco para o botão de confirmação após o primeiro evento ser
manipulado. Mas eu examinei o código e não estou imediatamente
certo se A, B, ou algo inteiramente diferente é verdade.

Obrigado.

@ndarilek Ao acionar o botão que adiciona um novo evento de entrada, ele apresentará um menu suspenso com quatro opções:

• Chave
• Botão Alegria
• Eixo da Alegria
• Botão do mouse

A opção Chave exibe uma caixa de diálogo modal (em cima da existente) que solicita ao usuário que pressione uma tecla (ou uma tecla com modificadores, por exemplo, Ctrl+K). Se o usuário pressionar outra tecla antes de confirmar, ela substituirá a tecla que foi definida atualmente na caixa de diálogo de confirmação. Esta caixa de diálogo continuará ouvindo eventos de teclado até que o usuário confirme clicando em "OK" ou cancele clicando em "Cancelar" na caixa de diálogo. Como esta caixa de diálogo escuta todas as teclas (incluindo teclas "especiais", como Tab), a navegação pelo teclado não é possível. Isso ocorre porque a caixa de diálogo substituirá a opção atual por Tab. Da mesma forma, a tecla Escape não pode ser usada para cancelar a caixa de diálogo. Devemos procurar melhorar a usabilidade deste diálogo :slightly_smiling_face:

Em contraste, os outros tipos (Botão Joy, Joy Axis e Mouse Button) não escutam eventos, eles apenas usam menus suspensos em diálogos modais.

Entendi. Então eu acho que, para fins de acessibilidade, vou arbitrariamente
decidir que a primeira chave nesta caixa de diálogo "ganha" quando o plugin é
em execução, então as pressões subsequentes de tab/enter/escape fazem o que deveriam
para. Descobri que redirecionar o foco para o botão OK quando neste
diálogo faz com que qualquer tecla usada para acionar o botão não seja salva.
Ou seja, se eu usar o Espaço para acionar a caixa de diálogo, então Enter para
acione o botão OK, o espaço é salvo como a chave, não Enter.

Então aqui está o comportamento que estou testemunhando agora, e gostaria de saber se alguém
tem alguma opinião sobre o que fazer sobre isso. Eu aciono o botão que abre
a caixa de diálogo ao pressionar "ui_accept", então Space ou Enter por padrão. Quando eu
acionar a caixa de diálogo, qualquer tecla que eu use para acionar a caixa de diálogo para aparecer
é a chave definida para o comando. Então, como acima, se eu usar o Space para acionar
ui_accept e Enter para fechar a caixa de diálogo, meu comando é definido como Espaço.
Da mesma forma, se eu acionar a caixa de diálogo para aparecer com Enter e usar Espaço para
pressione o botão OK, o comando está vinculado a Enter.

Acho que o que está acontecendo é que meu evento de imprensa envia o sinal para
clique no botão, que por sua vez abre a caixa de diálogo ouvindo a chave
eventos. Essa caixa de diálogo obtém a liberação da tecla que acabei de pressionar
(ou seja, espaço) e o define como o comando. Gostaria de saber se alguém tem
pensamentos sobre como contornar isso? Eu tentei is_action_released
em vez de is_action_pressed , meu pensamento é que ele detectaria
a liberação da ação pressionada de alguma forma e acionar isso, mas sem dados.

Aqui está o meu código. Essencialmente, identifica o botão selecionado a ser
clicado e, em seguida, envia o sinal. Existe alguma maneira de eu fazer o nó
aceitar todo o evento, incluindo o seu lançamento? Ou há algo
mais acontecendo aqui que está fazendo com que a liberação do evento alcance a caixa de diálogo
e acionar a captura? Sugestões são bem-vindas - estou aprendendo GDScript com
pulando no fundo do poço, então não tenha a menor idéia:

var button_index


func tree_input(event):
     var item = node.get_selected()
     var column
     if item:
         for i in range(node.columns):
             if item.is_selected(i):
                 column = i
                 break

     # button_index is set to 0 in an item_selected callback based on 
get_button_count(...) != 0

     if item and column and button_index != null:
         if event.is_action_pressed("ui_accept"):
             node.accept_event() # How can I accept the corresponding 
release of the press here so it doesn't leak through?
             return node.emit_signal("button_pressed", item, column, 
button_index + 1)
         var new_button_index = button_index
         if event.is_action_pressed("ui_home"):
             node.accept_event()
             new_button_index += 1
             if new_button_index >= item.get_button_count(column):
                 new_button_index = 0
         elif event.is_action_pressed("ui_end"):
             node.accept_event()
             new_button_index -= 1
             if new_button_index < 0:
                 new_button_index = item.get_button_count(column) - 1
         if new_button_index != button_index:
             button_index = new_button_index
             var tooltip = item.get_button_tooltip(column, button_index)
             var text = ""
             if tooltip:
                 text += tooltip + ": "
             text += "button"
             tts.speak(text, true)

Acabei de pensar em algo @ndarilek. Além do fato de que AFAICT não há como "clicar com o botão direito" do teclado, alguns comandos do teclado (por exemplo, Del) dependem do que está focado/selecionado. Sua combinação Godot/leitor de tela informa isso ou precisaríamos de uma anotação (provavelmente em "meta")?

Se você quer dizer determinar qual nó atualmente tem foco, eu acompanho
focus_entered e muitos outros sinais para relatar mudanças via fala.

E estou simulando cliques esquerdos do mouse, então provavelmente vou ramificar para
cliques com o botão direito em breve. No entanto, tendo encontrado a lista de atalhos de teclado
no editor junto com os botões New Script/Scene, isso não é tão
imediatamente crítico.

Solução hacky encontrada. A única circunstância que encontrei onde um
AcceptDialog fica em foco nesta caixa de diálogo para definir atalhos de teclado. assim
se isso acontecer, eu adiciono um timer oneshot por 5 segundos que fecha automaticamente o
diálogo. Nesses 5 segundos, você pressiona qualquer combinação de teclas que desejar
atribuído a essa ação e a caixa de diálogo confirma a alteração automaticamente.

Isso é hacky pra caralho, então se alguém tiver uma solução melhor, então eu sou tudo
ouvidos. :) Talvez eu também precise adicionar uma propriedade meta obscura a esta caixa de diálogo
no mecanismo para que o plug-in de acessibilidade saiba o caso especial e
anunciar instruções para pressionar uma tecla.

Com isso, posso adicionar ações ao meu jogo e responder a
eles. Agora tenho chaves para falar as coordenadas do meu jogador, rumo, etc.
bem como para sair do jogo. Acho que estou chegando perto de ser capaz de
desenvolver jogos de áudio simples com minha interface acessível.

Então, naturalmente, eu tenho outra pergunta. :) Existe um sinal de que eu posso
gancho no meu EditorPlugin para detectar quando o jogo que estou executando sai?
Quando o editor é inicializado, tenho que definir um foco inicial de interface do usuário para
que Tab/Shift-Tab pode até navegar, caso contrário, não há foco atual
para encontrar um foco seguinte/anterior. Mas quando um jogo lançado sai,
o foco não está definido e não localizei um sinal para pegar para lidar
naquela. Presumivelmente, algo tão significativo quanto lançar um
árvore de jogo/cena dentro do editor não simplesmente desaparece sem enviar um
sinal.

Ufa, e a estrada segue em frente...

Eu não acho que haja algo, mas você poderia usar WM_NOTIFICATION_QUIT em seu script de jogo de alguma forma, talvez? Enviar uma variável booleana para o EditorPlugin? (Embora eu tenha usado WM_NOTIFICATION_QUIT para salvar automaticamente na saída, quase não usei EditorPlugin)

Hmm, o que é WM_NOTIFICATION_QUIT?

E o que acontece visualmente na janela do editor quando executo um jogo? eu sei
o jogo aparece em uma janela separada, mas faz qualquer coisa no editor
mudança? Querendo saber se ele muda para uma tela diferente ou algo assim. eu
veja isso no meu console:

Executando: /home/nolan/src/godot/bin/godot.x11.tools.64 --path
/home/nolan/Projects/godot-accessibility --remote-debug 127.0.0.1:6007
--allow_focus_steal_pid 32312 --posição 328.225

o que me sugere que talvez a própria interface mude para
algo que ainda não está acessível, mesmo após o jogo fechar.

NOTIFICATION_WM_QUIT_REQUEST é um identificador de notificação (é definido em MainLoop).

Por exemplo, você pode reagir a notificações no GDScript escrevendo uma função _notification(what) :

func _notification(what):
    if what == NOTIFICATION_WM_QUIT_REQUEST:
        print("User requested the project to quit")

Você também pode fazer o Godot não sair automaticamente quando o usuário clicar no botão "Fechar" ou pressionar Alt+F4. Consulte Tratamento de solicitações de desligamento na documentação.

Para responder à sua última pergunta, o painel Saída do editor será aberto automaticamente quando você executar um jogo por padrão. Esse comportamento pode ser desabilitado desmarcando Run > Output > Always Open Output On Play nas configurações do editor. Ele permanecerá aberto depois que você fechar o jogo, a menos que você marque Executar > Saída > Sempre fechar saída ao parar nas configurações do editor.

Este painel exibe todas as mensagens impressas pelo jogo em execução e está localizado na parte inferior da janela do editor. Quando o projeto não está em execução, ele pode ser expandido ou dobrado manualmente clicando nele.

Olá,

Como posso testar isso no Windows?

Obrigado,

O teste do Windows é um pouco arriscado agora. Primeiro você precisa compilar
godot-tts , que é
Baseado em Rust, e requer a configuração do Rust's Tolkbiblioteca e executando uma tela
leitor. O mantenedor do Tolk-rs não está trabalhando ativamente no projeto
mais, mas me ofereci para assumi-lo e torná-lo um pouco mais fácil de
trabalhar com. Eu passo a maior parte do meu tempo no Linux, então o Windows não é um
prioridade. Você também precisa do meu garfo domotor .

Então, em suma, muito difícil no Windows agora. Ajuda nessa frente
muito apreciado. É factível - eu só tenho minhas mãos cheias.

Provavelmente vou montar um screencast em uma semana ou duas exibindo
o que é possível até agora e recrutar ajuda. Então você pelo menos será capaz
para vê-lo em ação.

Obrigado,

Ok, desenvolvimento nativo não é um ponto forte no meu caso...

Vou tentar me construir.

De qualquer forma, eu consegui isso ao tentar construir godot-tts

   Compiling gdnative-sys v0.5.0
error: failed to run custom build command for `gdnative-sys v0.5.0`

Caused by:
  process didn't exit successfully: `C:\Users\Franci\source\repos\godot-tts\target\debug\build\gdnative-sys-01490563416791dd\build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Unable to find libclang: "couldn\'t find any of [\'clang.dll\', \'libclang.dll\'], set the LIBCLANG_PATH environment variable to a path where one of these files can be found (skipped: [])"', src\libcore\result.rs:999:5

Então estou preso...

Hmm, eu tenho o seguinte no meu EditorPlugin :

func _notification(what):
     print("Notified: %s" % what)
     if what == MainLoop.NOTIFICATION_WM_QUIT_REQUEST:
         print("User requested the project to quit")

Isso imprime coisas, mas nunca "Usuário solicitou o encerramento do projeto",
mesmo quando eu saio do editor em si. Pensamentos?

Além disso, tentei um experimento em que fiz cada nó
foco no teclado / mouse, pensando que deve fazer o foco pousar em algum lugar
a partir do qual eu poderia tab. Comecei então a imprimir em focus_exited , e
descobriu que o foco é removido de onde ele parou no jogo
lançar. Portanto, não está, de fato, pousando em algum lugar fora de foco. Isso é
em nenhum lugar.

Por enquanto, tenho uma solução alternativa em que defino um foco inicial na tela
mude se nada estiver focado, então pressionar F1-F3 faz as coisas funcionarem
novamente. É possível que um EditorPlugin intercepte a entrada da GUI? eu
veja um método `forward_gui_input_ (ou algo semelhante, os documentos não estão abertos
agora), mas não está documentado. Nesse caso, posso capturar a entrada e definir o foco
em algum lugar se o foco não estiver definido.

Obrigado.

Perguntei isso no fórum, mas não obtive resposta. Este trabalho depende
em um plugin GDNative TTS que escrevi. Posso disponibilizar plugins GDNative
para outros usarem e, em caso afirmativo, como? Eu não quero dizer como compilar e
configurar CI, mas sim:

* Existe uma maneira padrão de fazer um arquivo de binários compilados
disponível para outros plugins/jogos usarem? Presumivelmente, as pessoas não são
espera-se que criem bibliotecas GDNative de terceiros nos casos em que são
exportar para outras plataformas. Ou são GDNative pré-criadas de terceiros
plugins não é uma coisa?

* Tenho const TTS = preload("res://godot-tts/godot_tts.gdns") no meu
roteiro. Isso pressupõe um local definido para minha biblioteca de plugins. Da mesma forma, o
as próprias bibliotecas têm caminhos res:// que assumem localizações em
res://godot-tts/target/debug. Eu não quero impor um layout de projeto em
alguém, então estou querendo saber se algum desses caminhos pode ser relativo?

Obrigado.

• Existe uma maneira padrão de fazer um arquivo de binários compilados
  disponível para outros plugins/jogos usarem? Presumivelmente, as pessoas não são
  espera-se que criem bibliotecas GDNative de terceiros nos casos em que são
  exportar para outras plataformas. Ou são GDNative pré-criadas de terceiros
  plugins não é uma coisa?

Infelizmente, ainda não existe um padrão para isso, então você terá que compilar bibliotecas e disponibilizá-las usando GitHub Releases ou similar.

• Eu tenho const TTS = preload("res://godot-tts/godot_tts.gdns") no meu
  roteiro. Isso pressupõe um local definido para minha biblioteca de plugins. Da mesma forma, o
  as próprias bibliotecas têm caminhos res:// que assumem localizações em
  res://godot-tts/target/debug. Eu não quero impor um layout de projeto em
  alguém, então estou querendo saber se algum desses caminhos pode ser relativo?

Eu não acho que você pode fazer o GDNativeLibrary usar caminhos relativos (a menos que você o crie em tempo de execução, mas isso parece bastante complicado). Ainda assim, os complementos geralmente estão localizados em res://addons , que é o local padrão usado pelos plugins do editor. Portanto, você pode pedir aos usuários que coloquem tudo em res://addons/godot-tts , o que deve funcionar bem com a maioria dos projetos.

Ah, OK, então basicamente construa uma versão do GitHub ou equivalente contendo meu
binários/docs/whatever pré-construídos e enviar tudo configurado para
recomendar e usar res://addons/godot-tts? Legal, obrigado, ajudou!

Eu acho que, depois de adicionar suporte para definir propriedades de nó de
editor, começarei a trabalhar em jogos de áudio reais para ver até onde vou.

Infelizmente, estou lutando para fazer algumas das propriedades um pouco
mais acessibilidade. Especificamente, adicionei suporte ao teclado para
expandir/recolher EditorInspectorSection, ponto em que posso percorrer
quaisquer propriedades contidas. O que não posso fazer é obter rótulos para
some--EditorPropertyVector2, por exemplo.

Suponho que existam rótulos de texto para estes em algum lugar? Eles não são feitos
disponível como instâncias Label . Alguém poderia me indicar onde
esses rótulos de propriedade são renderizados? Estou raspando a árvore tentando encontrar
eles, mas estou chegando em branco.

Muitíssimo obrigado.

EditorPropertyVector2 exibe dois campos (EditorSpinSlider) marcados como "x" e "y". Esses EditorSpinSliders são filhos de um VBoxContainer por padrão, ou um HBoxContainer se interface/inspector/horizontal_vector2_editing estiver habilitado nas configurações do editor.

A renderização inicial é feita aqui: https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/editor/editor_properties.cpp#L1150 -L1181

Desculpe, não fui claro. Onde o rótulo dessa propriedade é renderizado?
Presumivelmente em um Node2D, uma dessas propriedades referencia a posição. Eu estou
perguntando como encontrar o texto do rótulo para essa propriedade, já que
não aparece como Label em nenhum lugar que eu possa encontrar.

Desculpe se estou perdendo - encontrei o EditorPropertyVector2
implementação há algum tempo, mas parece apenas renderizar a interface do usuário para
definindo a propriedade e não seu rótulo associado.

Obrigado.

Os rótulos (assim como tudo que @Calinou mencionou) são renderizados no inspetor.

De cima, o do inspetor contém o seguinte:
Inspetor | Nó (essas são duas guias)
[nome do nó que você está inspecionando, por exemplo, "marcador"]
uma caixa de texto para filtrar propriedades
[Cabeçalho de variáveis ​​de script (opcional), com uma seta para recolher]
[qualquer variável de script exportada aparece aqui]
[classe de nó que você está inspecionando, por exemplo, Node2D]
[Cabeçalho de transformação - com uma pequena seta que permite recolher a seção]
Rótulo de posição - renderizado à esquerda das duas caixas que o EditorPropertyVector2 cria
Grau de rotação - idem, à esquerda de uma única caixa de entrada de texto
Rótulo da escala - igual à posição, as duas caixas são rotuladas x, y da mesma forma que a Posição
[Cabeçalho do Índice Z]
[super classe de nó que você está inspecionando, por exemplo, CanvasItem no caso de um Node2D]
[Cabeçalho de visibilidade, com uma seta...]
[Rótulo visível ao lado de uma caixa de seleção]
[Dois seletores de cores]
[Mostrar atrás do rótulo pai ao lado de uma caixa de seleção]
[Máscara de camada - um recipiente complexo cheio de pequenas caixas]
[Cabeçalho de material, com uma seta...]
[Node label] - é uma super super classe da qual cada nó herda, então está sempre na parte inferior
Esta seção sempre contém dois cabeçalhos, ambos com setas para dobrar:
[Pausa - uma lista suspensa]
[Script - uma lista suspensa que permite selecionar um script]

Para, por exemplo, nós 3D, o inspetor pode ficar muito complexo - esse foi apenas um exemplo simples do Node2D que descrevi, estou pensando que sua melhor aposta é criar um atalho para acessar rapidamente as coisas mais importantes - a seção Transform e Pause/Script em na parte inferior, e você sempre pode navegar facilmente para as propriedades exportadas porque elas estão na parte superior.

PS Se você selecionar a guia Node na parte superior, ele abre um menu completamente diferente no lugar do Inspector.

PPS. Se você filtrar as propriedades, terá apenas os rótulos, por exemplo, Node2D, e apenas um cabeçalho (do tipo que possui a seta para recolher) que contém a propriedade desejada. Acabei de verificar e você pode filtrar uma propriedade interna, como posição, então isso pode economizar muito tempo :)

Ah, eu percebi. Esqueceu que os pais de um nó não são necessariamente
suas superclasses. Nesse caso, eu tinha um cheque simples de node is EditorProperty e falava seu rótulo se um fosse definido. Neste caso, o
LineEdit para a posição que os componentes X/Y têm em sua árvore ancestral de nós
um EditorPropertyVector2 que, por sua vez, tem o rótulo.

Legal, agora temos rótulos falando por propriedades do editor no
inspetor. Obrigado pela descrição do layout também. Isso ajuda. Indo
ter que pensar em como tornar isso mais acessível.

Parece que os rótulos de propriedade não são desenhados usando nós, mas sim usando chamadas draw_string() de baixo nível. (Tente procurar por draw_string em editor/editor_inspector.cpp .) Não tenho certeza de como eles podem ser acessíveis, ou se será necessário transformá-los em nós.

Para referência futura, aqui estão algumas informações adicionais sobre EditorInspector/EditorProperty. Eu escrevi isso antes de procurar por instâncias de draw_string() , então o que segue pode ser supérfluo.

Não brinquei muito com o código do inspetor do editor, mas pelo que entendi, as propriedades do editor são adicionadas a uma estrutura AddedEditor quando são registradas: https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/editor/ editor_inspector.cpp#L865 -L873

Essa estrutura AddedEditor tem uma string label , que será passada para nós EditorProperty instanciados: https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/editor/editor_inspector.cpp#L1320 -L1367

Por fim, essa string label é usada para preencher o nó Label usando EditorProperty::set_label_reference , mas somente se a edição horizontal do Vector2 estiver desabilitada: https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/ editor/editor_properties.cpp#L1178

Caso contrário, EditorProperty::set_bottom_editor será usado para colocar o editor abaixo do rótulo: https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/editor/editor_properties.cpp#L1158

Agora tenho a tecla Menu acionando cliques com o botão direito. Isso parece permitir
interação programática com linhas em árvores.

Também corrigi alguns problemas ao calcular o texto para itens PopupMenu . Isto
tem o benefício adicional de que muitos itens que eu achava que não eram rotulados, na verdade são.

Agora os itens de menu do botão direito nas árvores estão acessíveis, ou pelo menos
parcialmente. Parece que estou enfrentando alguns problemas isolados que são
difícil de diagnosticar.

Chegando la...

Eu prometo não sequestrar este problema para este propósito, mas onde está o
melhor lugar para obter ajuda com perguntas gerais usando o mecanismo?

Há alguns dias, descobri que os fluxos de áudio 2D parecem pressupor
que eles são panorâmicos/atenuados do centro da tela e não tomem
rotação em conta. Isso não é o que eu quero de um jogo de áudio de cima para baixo
que terá rotação, possivelmente fontes de som fora da tela ouvidas no
distância, etc. Os documentos da janela de visualização parecem indicar que o áudio 3-D está
possível mesmo para nós 2-D, mas não estou claro se posso apenas adicionar um 3-D
stream player para nós 2-D e ter suas posições sincronizadas, se eu precisar
sincronize as posições X e Z manualmente com o 2-DX/Y e fixe os streams
Y para 0, se eu tiver que descobrir como usar uma câmera orto e renderizar
Objetos 3-D em 2-D, etc.

eu perguntei
isto
e tentei postar
isto
no Reddit, mas o primeiro não tem respostas e o último não é visível.
Não sei se não recebo o Reddit, se preciso ser aprovado etc.

De qualquer forma, não quero transformar esse problema em um tópico de suporte, mas estou
usando Godot de uma maneira incomum, e pode se tornar impossível mesmo
depois de fazer todo esse trabalho. Estou preparado para isso - decidi dar uma
mês para levar isso adiante e ver até onde eu chego - mas parte
de ter sucesso aqui envolve saber se o que eu quero é mesmo
alcançável mesmo com acessibilidade. E se eu puder criar um jogo de áudio
ambiente de desenvolvimento, estarei reunindo materiais para mostrar
outros como fazê-lo, então espero que meus aprendizados possam ajudar os outros. Mas eu
tendo dificuldade em obter respostas para essas perguntas de nicho, e isso
parece ser o gargalo desta semana.

Em outras notícias, também estou trabalhando na automação de compilações do Windows do TTS
plugin, e montamos um projeto inicial acessível tornando-o
fácil tanto demonstrar meu trabalho quanto criar em um ambiente acessível. eu vou
atualização quando eu tiver compilações binárias do plugin TTS disponíveis para download.

Obrigado.

A adição de um nó Listener2D foi solicitada em https://github.com/godotengine/godot-proposals/issues/49. Ele permitiria configurar de onde o som está sendo ouvido em uma cena 2D, como já pode ser feito em 3D com o nó Listener.

Posso confirmar que a postagem do Reddit aparece como removida, não sei por quê. Eu aprovei manualmente, mas provavelmente não aparecerá na primeira página como foi postado ontem. Tente postar novamente, deve estar tudo bem por enquanto :)

Ui, tão frustrante. Acabei de reenviar a postagem, visualizada em uma guia privada,
mostra como removido novamente.

Obrigado pelo link da proposta.

Desculpe usar este problema para suporte como este.

O progresso diminuiu um pouco enquanto eu tentava batalhar com o Appveyor para construir
o plug-in TTS no Windows. Eu já desisti dessa bagunça quente, e
provavelmente provisionará minha própria VM do Windows em breve e configurará um
Executor de CI do GitLab. Se alguém tiver uma VM do Windows disponível para
esse propósito, eu aprecio isso.

Os painéis agora são focalizáveis. Isso corrige o problema da semana passada em que sair de um
jogo no editor quebrou o foco do teclado.

Eu também refatorei um pouco o plugin TTS para rotear chamadas através de um TTS.gd
roteiro. Por enquanto, isso envia todas as chamadas para a biblioteca nativa do Rust, mas
versões futuras podem enviar chamadas para um módulo Java/Kotlin no Android,
etc.

Também estou trabalhando um pouco no meu primeiro jogo Godot, um áudio espacial
versão de asteróides. A distração do Appveyor da semana passada matou o progresso
nessa área, mas espero chegar a isso mais esta semana. Trabalhando em
navegação, envolvimento, falar coordenadas/direção, etc. Eu também tive que
hackear a falta de áudio espacial 2-D, o que acho que fiz, mas
ainda tem que testar.

@francipvb Você já tentou instalar o Clang/LLVM? Na verdade, estou tentando criar os mais recentes godot-tts no Windows também e descobrindo que provavelmente preciso do clang instalado. A compilação funciona no Appveyor, então suspeito que eles a tenham instalado lá e pode ser a peça que faltava.

Posso tentar isso ainda esta semana, mas o Godot não é executado na minha VM do Windows, portanto, mesmo que funcione, ficarei limitado na quantidade de testes do Windows que posso fazer.

Eu tenho um iniciador acessível que configura uma estrutura de diretórios na qual você pode compilar godot-tts. Ignore as instruções para buscar a compilação godot-tts do Appveyor. Não consigo descobrir como combinar compilações Linux e Windows em um único zip, então estou abandonando isso em favor de configurar meu próprio runner GitLab CI. Mas como não posso executar Godot no Windows atualmente, isso está sendo rebaixado em prioridade por enquanto.

Posso tentar isso ainda esta semana, mas o Godot não é executado na minha VM do Windows, portanto, mesmo que funcione, ficarei limitado na quantidade de testes do Windows que posso fazer.

Você deve poder instalar uma implementação de software OpenGL na VM: https://github.com/pal1000/mesa-dist-win

Godot será executado lentamente, mas desta forma, ambos os renderizadores GLES3 e GLES2 funcionarão.

@francipvb Você já tentou instalar o Clang/LLVM? Na verdade, estou tentando criar os mais recentes godot-tts no Windows também e descobrindo que provavelmente preciso do clang instalado. A compilação funciona no Appveyor, então suspeito que eles a tenham instalado lá e pode ser a peça que faltava.

Posso tentar isso ainda esta semana, mas o Godot não é executado na minha VM do Windows, portanto, mesmo que funcione, ficarei limitado na quantidade de testes do Windows que posso fazer.

Eu tenho um iniciador acessível que configura uma estrutura de diretórios na qual você pode compilar godot-tts. Ignore as instruções para buscar a compilação godot-tts do Appveyor. Não consigo descobrir como combinar compilações Linux e Windows em um único zip, então estou abandonando isso em favor de configurar meu próprio runner GitLab CI. Mas como não posso executar Godot no Windows atualmente, isso está sendo rebaixado em prioridade por enquanto.

Eu deixei isso intocado, mas vou tentar.

Saúde,

Olá @ndarilek ,

Eu desisti de tentar isso. Eu instalei a cadeia de ferramentas LLVM e funcionou.

Saúde,

Doce! Você quer dizer que compilou ou realmente fala no Windows?
Ainda não tive a chance de tentar fazer o software OpenGL funcionar.

Acho que tenho uma implementação OpenGL (tenho uma GPU NVIDIA).

Estou apenas construindo seu ramo godot.

Olá,

Como eu conecto essas duas coisas agora?

Obrigado,

Observe que eu construí o branch do github.

Eu acho que está bem documentado no README para o starter. Por favor deixe
me saber se você tem alguma dúvida sobre isso.

Desculpe, não tenho certeza de onde devo procurar, porque o repositório godot-tts não possui um README.

Saúde,

Oh, desculpe, pensei que você viu
isso .
Não siga as instruções de download do godot-tts, pois eles assumiram que eu
poderia fazer o Appveyor funcionar. E a última parte sobre perder o foco no jogo
desistir não é mais verdade.

Boa sorte, espero que isso funcione no Windows.

Tendo algumas lutas reais com os menus pop-up do botão direito que recebo quando
clicando em nós de árvore no editor.
Aqui
é o código com o qual estou trabalhando. Em particular, às vezes get_item_index
está retornando -1 e não sei por quê. Isso torna bastante
impossível obter quaisquer detalhes sobre um item PopupMenu , e os métodos para
fazer isso parece esperar um parâmetro idx que suponho ser um índice.

Olhando para a fonte, parece que -1 significa que o item não foi encontrado. Mas eu
passando o ID conforme recuperado por id_focused , então não sei por que isso
sinal me entregaria um ID que não foi encontrado.

De qualquer forma, tentei apenas inserir o ID quando recebo -1, mas isso é
claramente não está certo, pois costumo clicar em uma coisa e obter algo
inteiramente diferente. Ajuda com isso muito apreciada - passei horas em
e não sei se essas instâncias de controle específicas estão com bugs
ou se algo mais está acontecendo aqui. As coisas funcionam em outros menus, mas
não os menus de contexto do item de árvore na lista de nós. Obrigado.

Oh, desculpe, pensei que você viu isso . Não siga as instruções de download do godot-tts, pois eles assumiram que eu poderia fazer o Appveyor funcionar. E a última parte sobre perder o foco na saída do jogo não é mais verdade. Boa sorte, espero que isso funcione no Windows.

Aparentemente este link é para um repositório privado ...

Obrigado,

Doh, corrigido, desculpe.

Desculpe, não quero transformar isso em um tópico de suporte geral, mas
neste caso não sei se fiz algo errado e o editor está
sinalizando-o com um aviso ou se eu realmente cometi um erro. eu sou gentil
de fazer um pouco de fluxo de trabalho híbrido onde eu edito algumas coisas no
editor e então, com ele desligado, edite algumas coisas nos arquivos
mão. Então é possível que eu tenha feito algo errado, embora eu não esteja conseguindo
erros de sintaxe.

Não consigo reproduzir áudio 3D e montar issoexemplo para fazer coisas
o mais simples possível, mas não funciona. Minha intenção é criar um
único nó espacial 3-D com um ruído de fluxo de áudio e ouvinte como
crianças, então toque o estrondo. Isso funciona em 2-D, mas não em 3-D. Eu sou
fazendo algo errado aqui?

Peço desculpas novamente, perguntei no fórum semresposta ,
e tutoriais de texto são difíceis de encontrar. Às vezes eu não sei se
Estou encontrando um bug Godot, ou se o editor está sinalizando um erro e meu
plugin não está expondo-o.

Obrigado por qualquer ajuda. Além desse problema de áudio, estou fazendo algumas
progresso na navegação estilo Asteroids com uma interface falada. Lá
ainda são rugas, mas trabalhando com o editor Godot como um totalmente cego
desenvolvedor é factível até agora.

Eu quebrei o suporte de acessibilidade em um ScreenReader separado
nó que pode, teoricamente, ser adicionado a qualquer SceneTree para fazer
UIs no jogo acessíveis. Isso faz com que meu plugin não seja apenas um editor
aprimoramento de acessibilidade, mas um equivalente à acessibilidade do Unity
plugin que tem sido usado em muitos jogos de envio. Claro,
a funcionalidade ainda está atrasada, mas até onde eu sei,
A cadeia de ferramentas do Unity ainda não está acessível, então estamos à frente nesse sentido.

Não consigo reproduzir áudio 3-D e montar este exemplo para tornar as coisas o mais simples possível, mas não funciona. Minha intenção é criar um único nó espacial 3-D com um fluxo de áudio e ouvinte como filhos, depois tocar o ruído. Isso funciona em 2-D, mas não em 3-D. Estou fazendo algo errado aqui?

Você precisa adicionar um Camera 3D à cena. Você pode então colocar o ouvinte como um sub-filho da câmera e mover a câmera ou mover o ouvinte diretamente. Isso deve resolver o problema...

o que eu acho que é um bug, já que nenhum erro/aviso é exibido no editor quando nenhuma câmera está presente e o som não é reproduzido.

Ainda há rugas, mas trabalhar com o editor Godot como um desenvolvedor totalmente cego é factível até agora.

É emocionante ouvir isso, obrigado por seu trabalho em tornar Godot mais acessível.

Ah, eu pensei que o ouvinte era o suficiente. Posso adicionar a câmera e evitar
renderize enquanto ainda mantém qualquer propriedade que faça o
trabalho de ouvinte? Eu quero ser capaz de renderizar algo em 2-D, apenas
não uma cena 3-D completa. Ou posso ajustar a câmera 3-D para renderizar 2-D
de alguma forma - dar-lhe uma perspectiva ortogonal, talvez?

Obrigado, estou vasculhando as fontes tentando rastrear isso.

Ah, eu pensei que o ouvinte era o suficiente

Acho que deveria ser, pode ser um bug, não tenho muito conhecimento nessa área.

Posso adicionar a câmera e impedir que ela seja renderizada enquanto ainda mantenho qualquer propriedade que faça o ouvinte funcionar?

Você pode colocar todo o material 3d em um Viewport e ele não será renderizado (lembre-se de habilitar a propriedade listener).

Eu quero ser capaz de renderizar algo em 2-D, mas não uma cena 3-D completa. Ou posso ajustar a câmera 3-D para renderizar 2-D de alguma forma - dar uma perspectiva ortogonal talvez?

Você pode renderizar 3D em 2D (via ViewportContainer ) e 2D em 3D via ( Mesh , Material , ViewportTexture ).
Tem alguma documentação aqui:
https://docs.godotengine.org/en/3.1/tutorials/viewports/viewports.html
e projetos de demonstração aqui:
https://github.com/godotengine/godot-demo-projects
na subpasta viewport .

OK, eu tenho meu fluxo jogando! Já li muitos documentos e estou
também um pouco limitado pela minha incapacidade de ver o que está realmente sendo
renderizado, então espero que você não se importe com mais algumas perguntas inline. Eu estou
perguntando isso em outro lugar, mas este é o único lugar que estou recebendo
respostas, e peço desculpas a quem se sente spam, mas estou quase no
o ponto em que estou pensando em contratar um consultor Godot para ajudar com
este projeto de código aberto, que eu gostaria de evitar devido aos fundos limitados.
Mas minhas perguntas:

Em 25/09/19 10:38, Fabio Alessandrelli escreveu:
>

Você pode colocar todas as coisas 3d em uma |Viewport| e não vai render
(lembre-se de habilitar a propriedade listener).

Espere, eu pensei que era todo o ponto de vista de uma janela? Então soa
como o que você está dizendo que eu posso fazer é:

* Crie um jogo 2-D como estou atualmente, deixando-o renderizar para o
viewport padrão que é criada.

* Crie uma janela de visualização separada com uma câmera como criança e ouvinte
como um filho da câmera.

E, nesse caso, a câmera não renderizará nada, mesmo que a janela de visualização
é um filho da árvore de cena? Isso é porque seu tamanho é definido como 0 por
padrão, ou há algum outro motivo pelo qual eu possa processar o código em um
visor invisível? Isso é totalmente contra-intuitivo para mim, mas se isso
funciona, então isso simplificaria muito o meu trabalho. Eu também quero ter certeza
que a câmera continua a processar mesmo se a janela de visualização não estiver visível.

Meus nós AudioStreamPlayer3D precisam ser filhos da viewport como
Nós vamos? Na verdade, eu estava olhando através da fonte do motor, mas não era
imediatamente óbvio para mim que o ouvinte precisava ser uma criança câmera,
então não tenho certeza de como saber se os nós AudioStreamPlayer3D precisam ser
filhos da mesma viewport.

Obrigado novamente.

OK, atingindo outro problema estranho com o qual preciso de ajuda. Se eu adicionar um Raycast2D
nó, então tente definir sua propriedade de máscara de colisão através do editor, o
menu de camadas aparece quando pressiono Enter no botão. Mas pressionando
Entrar em uma camada parece não fechar o menu e selecionar uma camada.
Enter funciona bem em outros PopupMenus, que é o que parece ser.

Alguma idéia de por que isso pode estar acontecendo? E se não, alguém poderia por favor
me aponte para onde este menu em particular é implementado no motor para que eu
pode investigar? Bisbilhotou no editor/ mas não é imediatamente
óbvio, e também não tenho certeza de quais critérios específicos impediriam
alguns nós PopupMenu de responder a Enter. Talvez algo esteja
trabalhando em _gui_input e bloqueando-o?

Obrigado.

OK, atingindo outro problema estranho com o qual preciso de ajuda. Se eu adicionar um nó Raycast2D e tentar definir sua propriedade de máscara de colisão por meio do editor, o menu de camadas aparecerá quando eu pressionar Enter no botão. Mas pressionar Enter em uma camada não parece fechar o menu e selecionar uma camada.

Desculpe pela resposta demorada.
Sim, o PopMenu não é fechado automaticamente nesse caso.
Você precisa pressionar Esc para fechá-lo.
A ideia é que, quando você define a camada de colisão (que é um campo de máscara de bits), você pode querer definir mais de um bit de uma vez, para que o pop-up permaneça aberto.
O código relevante está configurando PopupMenu.hide_on_checkable_item_selection como false.
Ver:
https://docs.godotengine.org/en/3.1/classes/class_popupmenu.html#class -popupmenu-property-hide-on-checkable-item-selection

https://github.com/godotengine/godot/blob/master/editor/editor_properties.cpp#L799

https://github.com/godotengine/godot/blob/master/scene/gui/popup_menu.cpp#L1145

Desculpe, deveria ter mencionado que eu já tinha crackeado este. Eu estou
tentando não enviar spam demais a esse problema, se puder evitá-lo. :)

Fazendo um bom progresso, embora a maior parte esteja no meu jogo desde o
camada de acessibilidade está longe o suficiente. Ainda há muito mais para
fazer, porém.

Próxima pergunta, existe alguma maneira de interceptar e filtrar a tela sensível ao toque
interação antes de atingir Control s ou outros nós? Eu gostaria de
começar a trabalhar em algum tipo de suporte de exploração por toque, conforme encontrado em
VoiceOver para iOS ou TalkBack para Android, e também conforme implementado em
Plugin de acessibilidade do Unity. Essencialmente, eu gostaria de interceptar toques
para que seja necessário tocar duas vezes em um controle para acioná-lo, e
toques na tela servem apenas para revelar a interface. Deslizamentos rápidos para dentro
certas direções também funcionam como Tab/Shift-tab. não sei se preciso
sobreposições de viewport, algum tipo de camada personalizada que posso usar como
filtro, etc. Prefiro não alterar o comportamento de cada controle,
em vez disso, basta filtrar quais interações os atingem de uma maneira que pode ser
ativado e desativado durante a execução de um jogo.

Obrigado.

Próxima pergunta, existe alguma maneira de interceptar e filtrar a interação da tela sensível ao toque antes que ela atinja Control s ou outros nós?

Você pode usar Control._gui_input(event) no elemento raiz da GUI ou até mesmo Node._input(event) (possivelmente até na janela de visualização raiz).
Você pode então usar SceneTree.set_input_as_handled() ou Viewport.set_input_as_handled() para bloqueá-los depois de verificar o tipo de entrada para, por exemplo event is InputEventScreenTouch .

Verificação de saída:
Fluxo de eventos de entrada:
https://docs.godotengine.org/en/3.1/tutorials/inputs/inputevent.html

_input método em Node .
https://docs.godotengine.org/en/3.1/classes/class_node.html#class -node-method-input

set_input_as_handled() método em SceneTree .
https://docs.godotengine.org/en/3.1/classes/class_scenetree.html#class -scenetree-method-set-input-as-handled

_gui_input em Control
https://docs.godotengine.org/en/3.1/classes/class_control.html#class -control-method-gui-input

Obrigado, muito para olhar por aqui. Aqui está outro:

https://docs.godotengine.org/en/3.1/classes/class_itemlist.html#class -itemlist-method-select

"Nota: Este método não aciona o sinal de seleção de item." Por que é
naquela? Estou tendo que substituir alguns manipuladores de teclado em widgets porque,
por exemplo, pressionar a seta para baixo no item mais baixo de uma árvore/lista
foco deslizante em um widget vizinho em vez de simplesmente não avançar
a seleção. O mesmo com ItemList . Eu também estou tendo que implementar meu próprio
lógica de seleção. Um problema estranho que estou encontrando é no seletor de arquivos,
onde selecionar um item na lista não está atualizando o nome do arquivo na
campo de texto. Acabo tendo que selecionar o diretório em que o arquivo está,
em seguida, digite o nome do arquivo neste campo.

Dado que estou tendo que implementar minha própria lógica de foco de seleção, estou
perguntando se o fato de select não disparar o sinal pode ser
o que está causando isso? E isso levanta a questão, por que não select
disparar o sinal indicando que um item foi selecionado?

Obrigado.

OK, cheguei ao ponto de exportar um jogo que usa o
plugin de acessibilidade para sua interface do usuário. Isto está colocando um novo desafio que eu
não sabe abordar.

Eu tenho um código que tenta adivinhar um rótulo para alguns campos. Parte disso
algoritmo envolve percorrer os pais de um nó, encontrando qualquer
instâncias EditorProperty e retornando seus rótulos, se houver. Isto
funciona se eu executar meu jogo no editor, ou através de um binário que tenha o
editor embutido. Ele falha com um binário exportado, porque
EditorProperty não é definido em binários sem o editor. Coisas
Eu tentei:

if node.get_class() == "EditorProperty" não funciona porque eu preciso
a verificação is , não apenas igualdade de classe, e prefiro não verificar
se o nome da classe é igual a qualquer descendente do nome dessa classe.

if Engine.is_editor_hint() não funciona porque o código com falha ainda
é executado no binário exportado.

Posso recuperar uma classe por seu nome em uma variável e, em seguida, executar a lógica
com base em se a variável é nula ou não? Eu preciso executar um is
cheque ou equivalente. Caso contrário, posso mover este cheque para um
contexto separado que não é executado em binários exportados ou é avaliado como
nulo? Eu ainda quero que este código seja executado em geral, mas ficaria feliz em
mova as verificações específicas do editor para fora do caminho do código para exportações.

Para referência, aqui está o código que estou tentando fazer funcionar:

func guess_label():
     var tokens = PoolStringArray([])
     var to_check = node
     while to_check:
         if Engine.is_editor_hint():
             print(to_check)
             if to_check is EditorProperty and to_check.label:
                 tokens.append(to_check.label)
             if (to_check is EditorProperty or to_check.get_class() == 
"EditorInspectorCategory") and to_check.get_tooltip_text():
                 tokens.append(to_check.get_tooltip_text())
             var label = tokens.join(": ")
             if label:
                 return label
         to_check = to_check.get_parent()

Obrigado.

@ndarilek ,

Substituir um cheque is_class pelo cheque get_class resolveria esse problema? Os documentos para esse método estão aqui .

Sim, funcionou bem. Obrigado! A alternativa que eu estava considerando teria
ficou muito mais bagunçado.

Fico feliz em ouvi-lo. Voltei e li alguns desses posts e não é
totalmente claro quais são os problemas pendentes e o que foi resolvido,
mas você mencionou que há alguma dificuldade em descobrir o que está sendo
renderizado. Eu preciso deste plugin para um projeto em que estou trabalhando, então estou aberto a
ajudando onde quer que você precise de um desenvolvedor com visão para testar ou resolver
esquisitices estranhas. Sinta-se à vontade para entrar em contato comigo com o que você precisa fazer ou preencher
o rastreador de problemas em seus repositórios do gitlab com bugs e solicitações de recursos que você
preciso de ajuda e eu vou lidar com o que eu acho que posso gerenciar. Meu email é
ellen.h. [email protected]

Em segunda-feira, 14 de outubro de 2019, 9h50 Nolan Darilek [email protected]
escreveu:

Sim, funcionou bem. Obrigado! A alternativa que eu estava considerando teria
ficou muito mais bagunçado.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/14011?email_source=notifications&email_token=AAOY262NSXUDGOMDFEF5NPTQOSPOXA5CNFSM4EG4X6EKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBFRGQQ#issuecomment
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAOY264T3T7KWWSTBIIJUFLQOSPOXANCNFSM4EG4X6EA
.

Talvez possamos fechar este em breve, OTOH Eu tive muitas perguntas respondidas aqui que o IRC/os fóruns não ajudaram. Isso é verdade novamente. :) Espero ter mantido a relação S/R alta, mas quando preciso de ajuda com algo, geralmente está acima e além do que posso encontrar em um tutorial ou livro, e há muitas pessoas qualificadas observando esse problema e me ajudando construir esse suporte.

Fiz muito trabalho sobre isso durante as férias. Meu plugin godot-tts agora suporta Android e HTML 5, e exportei jogos acessíveis para ambas as plataformas. Também fiz alguns trabalhos iniciais na acessibilidade da tela sensível ao toque. No meu desktop Linux, as interfaces de usuário agora podem ser exploradas de forma acessível na minha tela sensível ao toque HDMI de US$ 70. Toques simples falam que o controle da interface do usuário está sendo tocado, um toque duplo em qualquer lugar na tela ativa o último controle focado e um deslize rápido para a direita/esquerda atua como Tab/Shift-tab e move o foco entre os elementos.

Infelizmente, passar o dedo não funciona no Android, e gostaria de ajuda para descobrir o porquê. Mais especificamente, os próprios furtos são detectados muito bem. Eles então injetam ações ui_focus_next ou ui_focus_prev usando um código como este:

func press_and_release(action):
    var event = InputEventAction.new()
    event.action = action
    event.pressed = true
    get_tree().input_event(event)
    event.pressed = false
    get_tree().input_event(event)

func swipe_right():
    press_and_release("ui_focus_next")

func swipe_left():
    press_and_release("ui_focus_prev")

E essas ações não são acionadas no Android, mesmo que as funções swipe_right / swipe_left funcionem bem. Alguma idéia de por que isso pode ser?

Conectei um teclado ao meu telefone e o Tab pelo menos aciona ui_focus_next . Portanto, a ação funciona em termos de reconhecimento, mas, conforme gerado pelo código acima, não parece ser acionado. Eu também tentei Input.action_press e Input.action_release , mas isso fez com que as coisas parassem de funcionar mesmo na área de trabalho. Então, claramente, meu código faz algo que Input.action_press não faz, mas não faz o suficiente para deixar o Android feliz. Tentei descobrir onde os eventos foram convertidos em ações, mas não está claro para mim se esses caminhos são específicos da plataforma. Claramente eles têm que ser desde que Linux/X11 e Android divergem.

Ficando sem ideias aqui e estou aberto a sugestões. Obrigado pela ajuda até agora.

Substituído por https://github.com/godotengine/godot-proposals/issues/983.

Observe que isso pode valer a pena dividir em uma proposta separada novamente. Estamos fechando propostas antigas neste repositório para incentivar a migração delas para o novo rastreador godot-proposals , onde queremos que todas as propostas residam e sejam discutidas.