GNOME Bugzilla – Bug 679965
RELATION_NODE_PARENT_OF no longer points to all children
Last modified: 2012-07-16 18:28:01 UTC
Steps to reproduce: 1. Launch gtk-demo for either gtk+ 2 or gtk+ 3. 2. Launch the tree store demo. 3. Examine the accessible relationships of the list and month cells. Expected results: The list would have an accessible RELATION_NODE_PARENT_OF relation pointing to 12 targets (one for each month). Actual results: The last has an accessible RELATION_NODE_PARENT_OF relation pointing only to 1 target (January). Note that all of the months have a RELATION_NODE_CHILD_OF relation pointing to the list, so only the inverse relation seems to have gotten broken along the way.
Created attachment 218871 [details] [review] Proposed patch. Gtk is calling atk_object_add_relationship more than once to add NODE_PARENT_OF relations. (Note that this happens lazily, as children are enumerated.) Anyway, only the first call succeeds. Following calls fail because the object already has a NODE_PARENT_OF relation. This patch makes atk_object_add_relationship call atk_relation_add_target if a relation is already present. The patch isn't exactly right, since atk_object_add_relationship is supposed to return TRUE if the relationship is added, and this patch always returns TRUE in that case (it should return FALSE if the target is already in the relation). Atk_relation_add_target is currently void, and I don't want to duplicate its functionality. Adding a return value to it might be another option (would that break ABI?) I think we could also just call atk_relation_set_add, since it duplicates the functionality of atk_object_add_relationship to some extent, the latter being a convenient wrapper. Atk_relation_set_add is also void currently. All of this assumes that we want to change atk_object_add_relationship, although I think we do.
Going to move this to atk (if we decide that atk is behaving as designed, then it should be moved somewhere else)
(In reply to comment #1) > Created an attachment (id=218871) [details] [review] > Proposed patch. > > Gtk is calling atk_object_add_relationship more than once to add NODE_PARENT_OF > relations. (Note that this happens lazily, as children are enumerated.) Anyway, > only the first call succeeds. Following calls fail because the object already > has a NODE_PARENT_OF relation. This is a regression still not solved. First detected on bug 578602 comment 6. I created bug 672869 to track this problem. The solution proposed was replace the test. From a test that just check if the relation contains a relationship, to a test that checks if the relation contains a relationship with the specific target. Something that (IMHO) follows the spirit of add_relation_ship. > This patch makes atk_object_add_relationship call atk_relation_add_target if a > relation is already present. The patch isn't exactly right, since > atk_object_add_relationship is supposed to return TRUE if the relationship is > added, and this patch always returns TRUE in that case (it should return FALSE > if the target is already in the relation). Atk_relation_add_target is currently > void, and I don't want to duplicate its functionality. Adding a return value to > it might be another option (would that break ABI?) I think we could also just > call atk_relation_set_add, since it duplicates the functionality of > atk_object_add_relationship to some extent, the latter being a convenient > wrapper. Atk_relation_set_add is also void currently. Yes, I agree that your patch have some issues. I still prefer the option proposed at bug 672869 > All of this assumes that we want to change atk_object_add_relationship, > although I think we do. I don't see any reason to change atk_object_add_relationship. As this bug was already submitted, and the patch at this bug is not 100% right, I will close the bug as duplicate. As some people (specifically Joanie) mentioned that the bug is important, I will try to solve bug 672869 for today release. *** This bug has been marked as a duplicate of bug 672869 ***