Add support to emit signal so that interested clients can be notified of Orca's current object of interest
Screen magnifiers might wish to zoom in on, highlight, whatever what Orca is currently presenting. As a result, Orca needs some way of notifying those tools. API was recently added to AT-SPI2 for this purpose, but it strikes me as a bad idea for the following reasons:
- It's specific to the accessible text interface. Not all object of interest that Orca is presenting will implement the accessible text interface. Thus it's incomplete.
- The result clients receive is just another AtspiText event (like caret-moved, selection-changed, etc.). There's no way of knowing that it came from Orca, or some other AT, or from the application/toolkit itself. Thus it's not sufficiently specific.
Orca could emit a signal (using g_signal_emit). There should be one, and only one signal. It should:
- Include the object of interest (must not be null)
- Include a startOffset (can be null)
- Include an endOffset (can be null)
I'm still debating where this signal should be emitted (i.e. what does the actual emission). I'm toying between orca.py and event_manager.py. Note that eventsynthesizer.py is where Orca fakes input events (mouse clicks, scrolling etc.). Thus this to-be-created signal doesn't belong there.
UPDATE/EDIT: Let's put it in orca.py.
Lastly: I am still giving some thought to where all scripts might wish to emit the event. Thus for now, merge requests that are limited to accomplishing the above WITHOUT adding calls to it to Orca will be prioritized for review.
@sthibaul Can I give this to you for implementation?