GNOME Bugzilla – Bug 640574
atk is missing annotations needed for gobject-introspection
Last modified: 2011-03-01 20:06:17 UTC
g-ir-scanner has trouble creating a gir for atk because it is missing some annotations (functions that return GObjects need transfer: annotations, and there are a few minor documentation issues).
Created attachment 179323 [details] [review] Proposed patch. This fixes most but not all of the issues. I believe the callback-related warnings will require an API change to be gobject-introspection-compatible, so we may need to wait until after the proposed ATk/AT-SPI hackfest when we break API. atk_text_get_bounded_ranges will also still not work with introspection, but the atk free function seems buggy, and I am not even sure how it is supposed to work or if anyone implements it (GAIL apparently does not).
[Setting GNOME Target to 3.0 as atk is in jhbuild's gnome-suites-core-deps-3.0.]
Maybe we want to add this bug to bug 638537?
(In reply to comment #0) > g-ir-scanner has trouble creating a gir for atk because it is missing some > annotations (functions that return GObjects need transfer: annotations, and > there are a few minor documentation issues). IMHO this is a duplicate of bug 635798 (In reply to comment #3) > Maybe we want to add this bug to bug 638537? The purpose of this bug is improve ATK adding/removing API, without the concern of any API breakage (so an ATK 2.0 would be an option). IMHO, annotations is required independently of this.
(In reply to comment #4) > (In reply to comment #3) > > Maybe we want to add this bug to bug 638537? > > The purpose of this bug is improve ATK adding/removing API, without the concern > of any API breakage (so an ATK 2.0 would be an option). IMHO, annotations is > required independently of this. Mike said "This fixes most but not all of the issues. I believe the callback-related warnings will require an API change to be gobject-introspection-compatible, so we may need to wait until after the proposed ATk/AT-SPI hackfest when we break API." So I thought to complete fix this bug, an API change is needed.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Maybe we want to add this bug to bug 638537? > > > > The purpose of this bug is improve ATK adding/removing API, without the concern > > of any API breakage (so an ATK 2.0 would be an option). IMHO, annotations is > > required independently of this. > > Mike said > "This fixes most but not all of the issues. I believe the callback-related > warnings will require an API change to be gobject-introspection-compatible, so > we may need to wait until after the proposed ATk/AT-SPI hackfest when we break > API." > > So I thought to complete fix this bug, an API change is needed. Ok, sorry I missed that comment. Yes it is true that probably any API change would be required for a full gobject introspection support (ie, on Cally, this change was required [1]). Anyway, in the same way it would be good that have as much gobject introspection as possible in the current atk 1.0. So I think that makes sense to apply this patch on atk 1.0 (as it is just about the annotations), and create a new bug to track the changes required for a fully supported gobject introspection. Something like "ATK API changes required to became atk fully introspectable". Opinions? [1] http://bugzilla.clutter-project.org/show_bug.cgi?id=2479
Sure! (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > Maybe we want to add this bug to bug 638537? > > > > > > The purpose of this bug is improve ATK adding/removing API, without the concern > > > of any API breakage (so an ATK 2.0 would be an option). IMHO, annotations is > > > required independently of this. > > > > Mike said > > "This fixes most but not all of the issues. I believe the callback-related > > warnings will require an API change to be gobject-introspection-compatible, so > > we may need to wait until after the proposed ATk/AT-SPI hackfest when we break > > API." > > > > So I thought to complete fix this bug, an API change is needed. > > Ok, sorry I missed that comment. Yes it is true that probably any API change > would be required for a full gobject introspection support (ie, on Cally, this > change was required [1]). > > Anyway, in the same way it would be good that have as much gobject > introspection as possible in the current atk 1.0. > > So I think that makes sense to apply this patch on atk 1.0 (as it is just about > the annotations), and create a new bug to track the changes required for a > fully supported gobject introspection. Something like "ATK API changes required > to became atk fully introspectable". > > Opinions? > > [1] http://bugzilla.clutter-project.org/show_bug.cgi?id=2479
Review of attachment 179323 [details] [review]: Feel free to commit the patch.
*** Bug 635798 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Sure! Bug 640625 created to track the changes that would require API breakage for a full gobject introspection support.
Created attachment 181607 [details] [review] Patch to generate introspection for atk_text_get_bounded_ranges. I also fixed a typo and what looks like a bug in atk_text_free_ranges; I'm guessing that function has never been tested because GAIL doesn't implement atk_text_get_bounded_ranges.
Review of attachment 181607 [details] [review]: I am OK with the patch. Does it break API? I am not sure since it adds a get_type function in the header file.
Well, after a quick check, it is an addition so no current API is affected. (In the same way it is not a new virtual method on a class structure, so it is not also a ABI break). IMHO, this doesn't break the API. BTW, just a question, there are two patches reviewed. Are both waiting to be applied or it is just the last one?
I've just committed the AtkTextRange patch. I committed the other patch a while ago.
Anything left to do here, or should this be closed ?
Yeah; should be closed. I thought I'd done that already. Thanks.