Should selection-changed fire when selected nodes become visible?
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- godot, rust
- Ambito
- accessibility
Direzione di ricerca
La issue non indica file, test o punti di ingresso. Inizia riproducendo il comportamento della selezione dell’albero della scena in Godot con Orca, quindi traccia quando viene emesso selection-changed per i nodi aggiunti con una selezione iniziale tra le diverse piattaforme. Il completamento richiede una regola concordata per stabilire se questo evento debba essere emesso e una copertura di regressione per questo comportamento.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Rust
- Stelle
- 1.5k
- Fork
- 115
- Merge medio
- 1g 8h
- PR unite (30g)
- 21
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di AccessKit/accesskit
-
Document sub-treesAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
Document `Role::ColorWell`Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
AccessKit/accesskit#802 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
AccessKit/accesskit#778 · 24 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
AccessKit/accesskit#749 · 9 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di AccessKit/accesskit
Issue simili
-
area:release bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
registrystack/registry-stack#1874 ·
I maintainer di solito rispondono entro 1 giorno
-
component:midnight-toolkit status:untriaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
midnightntwrk/midnight-node#2237 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno