Should selection-changed fire when selected nodes become visible?
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- godot, rust
- Área
- accessibility
Línea de trabajo
El issue no menciona archivos, tests ni puntos de entrada. Comienza reproduciendo el comportamiento de selección del scene tree en Godot con Orca y, después, rastrea cuándo se emite selection-changed para los nodos añadidos con una selección inicial en distintas plataformas. Para darlo por terminado, se requiere una regla acordada sobre si este evento debe activarse y cobertura de regresión para ese comportamiento.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I'm working on improving Godot accessibility. A pattern I've noticed, when
arrowing through the scene tree, is that a number of tab panels/lists become
visible as tree item selection changes. These start with an initial selection, generating a selection-changed
event when the node is added to the tree. Orca then
presents the selections from the newly visible nodes in addition to tree selection. In addition to being confusing, speech from the newly appeared list/tab selections usually cuts off selections from the tree, which is what you really want.
Nodes seem to generate selection-changed when added with selections. This behavior seems to exist on all platforms.
Should a selection change be generated when a node with selection is added but
not changed? My sense is not, and I'm happy to fix it if needed, but this
pattern exists everywhere so I thought I'd check before making an attempt.
- Lenguaje dominante
- Rust
- Estrellas
- 1.5k
- Forks
- 117
- Merge medio
- 6 h 5 min
- PR fusionados (30 d)
- 19
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de AccessKit/accesskit
-
Document sub-treesAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
Document `Role::ColorWell`Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
AccessKit/accesskit#802 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
AccessKit/accesskit#778 · 24 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
AccessKit/accesskit#749 · 9 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de AccessKit/accesskit
Issues similares
-
status:needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
agentic-os-org/ANOLISA#6742 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
git-ai-project/git-ai#2406 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
Kc1t/alethe-agents#312 ·
Los mantenedores suelen responder en 3 días