GNOME Bugzilla – Bug 638924
Implement AtkWindow
Last modified: 2011-08-16 17:08:49 UTC
at-spi expect window related methods (activate, deactivate, etc) from the ATK implementation toolkit, defined on the interface Window, at event.didl (at-spi2-core/idl). But the equivalent methods are not defined on ATK. That means that each implementation are emitting it as a private detail of the implementation, but not related with any Atk event. This also leads to hacky implementation of the method atk-add-global-event-listener, as it requires to provide the way to add a listener to ATK methods, and also this "out the ATK-law" methods. In my opinion that could be solved with an AtkWindow interface, with an API more or less equivalent to the defined on that at-spi interface Window.
ATK Hackfest Conclusions: * We will add this interface
[Mass-reassigning open atk bug reports for better trackability as requested in https://bugzilla.gnome.org/show_bug.cgi?id=653179 . PLEASE NOTE: If you have watched the previous assignee of this bug report as a workaround for actually getting notified of changes in atk bugs, you yourself will now have to add atk-maint@gnome.bugs to your watchlist at the bottom of https://bugzilla.gnome.org/userprefs.cgi?tab=email to keep watching atk bug reports in GNOME Bugzilla. Sorry for the noise: Feel free to filter for this comment in order to mass-delete the triggered bugmail.]
Created attachment 191498 [details] [review] Patch. Tested with gtk+ master after removing the window signal registrations. This patch seems disruptive to cally, but I'm not sure why--I haven't looked at the code or tried to debug. My inclination would be to commit it to atk-3. Also, I haven't added entries for the signals in the structure, as has generally been done for other ATK interfaces; let me know if you think these should be added.
(In reply to comment #3) > Created an attachment (id=191498) [details] [review] > Patch. > > Tested with gtk+ master after removing the window signal registrations. Did you also updated the signal emission? > This patch seems disruptive to cally, but I'm not sure why--I haven't looked at > the code or tried to debug. My inclination would be to commit it to atk-3. Ok, I will test it on cally. Anyway, once we get those thing solved, I think that it would be save to add this interface to atk-2 itself. > Also, I haven't added entries for the signals in the structure, as has > generally been done for other ATK interfaces; let me know if you think these > should be added. No, the current "policy" is avoid that unless it is really required. Review in progress.
Review of attachment 191498 [details] [review]: ::: atk/atkwindow.c @@ +1,3 @@ +/* ATK - Accessibility Toolkit + * Copyright 2001 Sun Microsystems Inc. + * As I said, date and company seems to no be the correct. @@ +57,3 @@ + return type; +} + How about use G_DEFINE_INTERFACE? Also related with bug 382323 ::: atk/atkwindow.h @@ +1,2 @@ +/* ATK - Accessibility Toolkit + * Copyright 2001 Sun Microsystems Inc. Probably you would prefer to use a different copyright here. @@ +40,3 @@ + +#ifndef _TYPEDEF_ATK_WINDOW_ +#define _TYPEDEF_ATK_WINDOW_ I saw this ifndefs in the other atk interfaces, but it is not used on gtk and clutter. It is really required? @@ +52,3 @@ + gpointer pad2; + gpointer pad3; + gpointer pad4; At this moment clutter does something like: gpointer _padding_dummy[28]; I think that this make things more readable.
(In reply to comment #4) > (In reply to comment #3) > > Created an attachment (id=191498) [details] [review] [details] [review] > > Patch. > > > > Tested with gtk+ master after removing the window signal registrations. > > Did you also updated the signal emission? > I haven't done anything to the signal emission so far--it is calling g_signal_lookup on g_signal_lookup on GTK_TYPE_WINDOW_ACCESSIBLE. It works if I implement AtkWindow but not if I don't implement AtkWindow.
Created attachment 191554 [details] [review] Updated patch. Thanks for the review. I copied that typedef over from another file; I don't know why it was there. I took it out, and it builds for me.
Created attachment 193579 [details] [review] Adding atkwindow on different places I guess that atk.symbols will be required for windows. I needed to add AtkWindow on atknoopobject because the bridge uses it to ensure that we have the gtype available for all the atk interfaces. And after all, it is supposed that that object implements all the interfaces.
> This patch seems disruptive to cally, but I'm not sure why--I haven't looked at > the code or tried to debug. My inclination would be to commit it to atk-3. Take a look to bug 649577. That "disruption" was related to the tests compiling or when using it? Although I still don't know why failed the test compilation, once solved I was able to test it using cally-atkkeyevents example, at tests/accessibility. Of course that will not work with the atk-bridge until a equivalent change to that example is made (registering window events with something like "Atk:AtkWindow:create" instead of the current "window:create"). Any other reason to postpone it to ATK3? > Also, I haven't added entries for the signals in the structure, as has > generally been done for other ATK interfaces; let me know if you think these > should be added. No, I'm ok with that. In the same way I just added a little patch with some minor issues. For me the patch is ok. But I will approve it once we get answered those questions.
(In reply to comment #9) > > This patch seems disruptive to cally, but I'm not sure why--I haven't looked at > > the code or tried to debug. My inclination would be to commit it to atk-3. > > Take a look to bug 649577. That "disruption" was related to the tests compiling > or when using it? Sorry typo: https://bugzilla.gnome.org/show_bug.cgi?id=656306#c4 Mike, had you got this error?
Created attachment 193977 [details] [review] Updated patch. Fix copyright.