Created attachment 194636 [details] [review]
GtkWindowAccessible implementing AtkWindow

Created attachment 194639 [details] [review]
Window events are not anymore a exception

The only doubt that I have here is about do_window_event_initialization.

Before this patch, this was done the first time you register to a window event. After this patch, it is done when you load Gtk AtkUtil implementation, so anytime you enable accessibility.

One option could be maintain that on the global event function, but the current plan is to move that function to ATK itself, so it would be good to avoid any specific toolkit code there.

But I really think that this is not a big issue, as probably you would require that initialization anytime you initialize the accessibility stuff.

Somwhat off-topic: In the same way it would be good to have a kind of atk_init in the future as that AtkUtil initialization has other initialization stuff (hash table)

some discussion of this api:

<mclasen> Company: did you want to take care of the atkwindow patch ?
<Company> mclasen: yeah, i did
<Company> mclasen: but by now i'm not sure it's useful
<Company> i suppose it doesn't hurt to just do it, but AtkWindow is a completely stupid API
<Company> but that's just because atspi is entirely braindead

[...]

<Company> it doesn't help one single bit with anything, its existance just makes stuff complicated
<mclasen> what is made more complicated ?
<Company> the signals are entirely 100% useless
<Company> all of them
<Company> most of them are equivalent to state-changed signals
<Company> move and resize are equivalent to bounds-changed
<Company> and create is equivalent to child-added on the root
<Company> they only exist for one reason: the only API that exists for signals in atspi is equivalent to g_signal_add_emission_hook()
<Company> so if you subscribe to state-changed you get all state-changed signals for all objects in existance and your dbus connection explodes

(In reply to comment #3)
> some discussion of this api:
> 
> <mclasen> Company: did you want to take care of the atkwindow patch ?
> <Company> mclasen: yeah, i did
> <Company> mclasen: but by now i'm not sure it's useful
> <Company> i suppose it doesn't hurt to just do it, but AtkWindow is a
> completely stupid API
> <Company> but that's just because atspi is entirely braindead
> 
> [...]
> 
> <Company> it doesn't help one single bit with anything, its existance just
> makes stuff complicated

The only reason to add that interface is removing the horrible hack required on the implementation of atk_add_global_event_listener. And IMHO thats useful.

> <mclasen> what is made more complicated ?
> <Company> the signals are entirely 100% useless
> <Company> all of them
> <Company> most of them are equivalent to state-changed signals
> <Company> move and resize are equivalent to bounds-changed
> <Company> and create is equivalent to child-added on the root
> <Company> they only exist for one reason: the only API that exists for signals
> in atspi is equivalent to g_signal_add_emission_hook()
> <Company> so if you subscribe to state-changed you get all state-changed
> signals for all objects in existance and your dbus connection explodes

As we already mentioned on IRC, for the ATs (specifically Orca) is useful to get a way to register to a specific window event. And yes, this is a inherent issue related to base the event listening on global events. But this is what we have right now. Move to a a11y framework not based on this behaviour is not a short term thing, and more an ATK3 thing.

I understand your worries about a interface or signals that could become obsolete in the future, but IMHO, I prefer to improve the current status on ATK2 while ATK3/AT-SPI(X) is getting form.