GNOME Bugzilla – Bug 647352
cleanup the atkrelationset interface
Last modified: 2021-06-10 11:27:16 UTC
atk_set_get_relation(relation set, index) should go away, there is no way for the caller to know what relation is at that index, or if there is even one at that index. This function just gives the caller a random relation from the set. So this function seems to never do the correct thing. if we get rid of the current atk_relation_set_get_relation() we can rename atk_relation_set_get_relation_by_type() to atk_relation_set_get_relation() we can also rename atk_relation-set_add_relation_by_type() to not have the by_type part since there is no other reasonable way to add a relation to the set.
It can be used in conjunction with atk_relation_set_get_n_relations to iterate through the set. at-spi2-atk currently uses it like so: if (set) count = atk_relation_set_get_n_relations (set); for (i = 0; i < count; i++) { AtkRelation *r = atk_relation_set_get_relation (set, i); .... } This assumes that the UI is not being modified in another thread, but, if we need to guard against that, then it is a much larger problem.
(In reply to comment #1) > It can be used in conjunction with atk_relation_set_get_n_relations to > iterate through the set. at-spi2-atk currently uses it like so: > > if (set) > count = atk_relation_set_get_n_relations (set); > for (i = 0; i < count; i++) > { > AtkRelation *r = atk_relation_set_get_relation (set, i); > .... > } Ok, I thought we had a way to get the array of relations but I gues not. <digression> Personally I find the decoupling of atk and atk-adaptor to be fairly odd and somewhat confusing, and would personaly be inclined to consider merging them into one library and just allow atk-adaptor to know about the internals of relations since it needs to send them over dbus so will know how to serialize them anyway. In which case these accessor wouldn't seem to make sense. </digression> I gues other options here include having a method something like atkObject* getRelations(int *numRelations) that returns a pointer to an array ofrelations andthe number ofrelations. alternatively at-spi2 could iterate over types instead offrom 0 to count. However nietherof those options seems very good. I'd like to see this interface a bit nicer, but I'm not really sure what the best option here is...
Actually, you're right--the AtkObject struct has a GPtrArray called relations, as it is now, so at-spi2-atk could be using this instead. We would probably want an accessor function for introspection purposes at least; I'm not sure if there is a way to mark an array in a structure to denote the type of data it will contain.
ATK Hackfest conclusion: What we have at the moment is working, and we have many other critical things to address. Therefore, we can revisit this in the future.
[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.]
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of atk, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/atk/-/issues/ Thank you for your understanding and your help.