There seem to be a small handful of cases where we want this--controls that gain focus immediately after a dialog appears, for instance. We allow these edge cases to indicate that the next focus shouldn't stop speech, then clear it on cases where speech isn't stopped. This is a bit hacky, but seems cleaner than anything else I came up with.
Trees appear to eat "ui_accept" before `gui_input` receives it. This makes certain use cases--triggering buttons in cells--impossible via the keyboard.
Here, `ScreenReader` attempts to intercept recent presses of "ui_accept" and, if a button in a cell should receive focus, redirects the `InputEvent` to the custom handler for `Tree`.
Unfortunately, this loses the ability to click buttons in cells in the editor's node tree for some reason. It restores, or maybe gets working in the first place, clicking on the _Remove_ button in the input mapping screen. Not sure how to restore the former functionality--these trees are complex and not well-documented.
That behavior is only specific to the editor. Any game UI that loses focus should be fixed by intelligently setting focus, not by magic in the accessibility addon.
UI controls occasionally trap focus and make navigation impossible. Now, Ctrl+escape toggles a mode that attempts to intercept and generate UI focus events and bypass the control's own handling. This can probably be refined, but for now it allows escaping of `TextEdit` via tab. It also won't work everywhere--inn particular, arrowing around still traps focus in trees. But it is at least possible to tab out of most traps.
Further, event generation was cleaned up some. We specifically need to generate `KeyEvents` under Android because, IIRC, it wasn't enough to simply create and send some types of events. We now have two distinct generation strategies. These can probably be combined and streamlined, but for now this works.
`Accessible` is now a child of its `Control`. This helps to ensure that everything gets cleaned up as it should. Further, node additions no longer scrape the entire scene.
This may introduce regressions and has only been lightly tested, but without it, `ScreenReader` leaked in various circumstances, including some that caused segfaults on exit.
This eliminates the need to track and iterate through a separate array of `Accessible`s in `ScreenReader`.
The previous performance issues are resolved by ensuring that any nodes processed aren't children of the `ScreenReader` node. I don't know of another way to avoid triggering signals on a child node than checking ancestry and failing fast.
Here I add a `ScreenReader` `Node` which, when added to the `SceneTree`, should read the contents of any supported `Control`. I also do a bit of cleanup on filenames, as well as breaking the editor plugin support into its own class.
