Remove all keyboard handling functionality

[TTWNO]

Our current implementation of keyboard handling is a hack, and this was known from the start. I think it's time we remove it.

This branch changes the name of a few input sockets, as well as completely removes all functionality related to keyboard handling.

I think for a first release, and absolute beta, we can get away without keyboard handling. Keyboard and tab navigation should work without the keyboard deamon.

If we're going to implement keyboard handling, let's do it right and not ship a half-baked feature.

[albertotirla]

I agree with this, but firstly we have to understand the implications of removing this feature and what things could be affected if we do so. Here's a non-exhaustive list of what's imediately obvious, feel free to correct it or add things to it as you see fit

• web browsing functionality: because we can't use browse mode and since quick navigation is required on today's internet, we basically can't use anything that can't be efficiently be used with focus mode, so the only thing we could use is a web app which is well suited to focus mode only browsing, aka google docks, visual studio code, etc
• caret navigation will be mostly broken, mostly on the web again: remember what I said a long time ago about how orca does caret changed events? well, firefox is so based around this mechanism that we don't even get caret changed events when moving through the lines of a paragraph, so we either have to rely on orca's mechanism which will be impossible to do now we don't have key handling anymore, or find a way for firefox to emit those events in all cases.
• in the future, we might lose stuff like object navigation and other things of that nature, but hopefully the problem will be solved till then.

So yeah, I do agree with you when it comes to delivering half-baked features, however at the same time, our 0.1.0 would be crippled in features way beyond what we actually have in the codebase prepaired for 0.1.0 itself. If you are ok with the previous list being true, at least temporarily, then go ahead, I'll merge. Be warned though, CI is failing, you have to fix that before I'll allow the merge.

[TTWNO]

caret navigation will be mostly broken, mostly on the web again: remember what I said a long time ago about how orca does caret changed events? well, firefox is so based around this mechanism that we don't even get caret changed events when moving through the lines of a paragraph, so we either have to rely on orca's mechanism which will be impossible to do now we don't have key handling anymore, or find a way for firefox to emit those events in all cases.

I don't know where you heard this, but this is false. I'm able to receive all the events regardless of if I have keybindings activatednor not. The issue is that caret navigation is not implemented—this is a basic feature that absolutely does need to be omplemented before 0.1.0

in the future, we might lose stuff like object navigation and other things of that nature, but hopefully the problem will be solved till then.

Again, no idea where you got this idea, but atspi events should be received regardless of wether we have a key handler or not.

[albertotirla]

@TTWNO
about firefox: the keyboard daemon running indeed has nothing to do with the caret. However, caret moved events aren't dispatched when you up and down arrow in a paragraph, aka in the same accessible component, for some reason. Which means, we basically have to use the other atspi methods on the text interface, there's one which accepts a start position and an enum with values such as word, sentence, character, etc, then it returns a string with the found text slices. I've seen orca checking if a key or key combo was pressed, to then invoke the appropriate method according to what key that was. Apparently, this was the only reliable way thought of at the time, also now the system is kinda built around it, especially with firefox and maybe others.
object nav: Of course, atspi events aren't gonna stop flowing just because an unrelated piece of the system dropped. What would probably happen for a while is that, while object nav could be implemented, we would have no way of specifying keybindings because no key daemon is present, but that's why I said this problem would probably be fixed in a not so distant future, along with the others, but it's nevertheless a consequence of removing keybinding support.

[TTWNO]

@albertotirla , again, this is false. It absolutely does sent text caret moved evenrs within the same accessible.