odilia should be silent on events which come from other applications than the focused one

[albertotirla]

On the accessibility bus, there's a lot of traffic, because most apps just shout into the void, even when there's nothing listening.

So, imagine you're turning on odilia, without redirecting to /dev/null or a log file. Maybe you want to see it in the tty later, or you just forgot the proper way of launching, etc, but it does happen

Currently, odilia keeps stumbling over, and interrupting, itself because it's trying to read too many text changes and events. Of course, this grows exponentially, because when it's reading something, the logs of that happening are also written, so yeah, this way odilia can't even speak anything basically and would be considered blocked by most. This would be relatively alright, and sometimes maybe even acceptable, if this was only happening while we were focused on the terminal. But even if we move away from the window, the issue still persists

What should happen instead is that, at the minimum, odilia should not speak any events which don't come from the currently focused application.

The way I thought of doing this is relatively simple:

• check the application part of the event you get
• if it's not the currently focused application, which, say, we keep in state, then simply return from the handler without doing anything
• otherwise, process event as usual

How do we find this? well, when we get a window opened event, the application field should be filled with the application who's window just opened, basically what the user is focused on. So then, we store a reference to that in state, against which we vet all events

on window closed, then, the focused app should be unset from state, so we know that during that small period of time between window switches we don't have an invalid state where we ignore some events

speaking of the window opened handler, perhaps odilia should also speak the title of the window, as extra credit.