GNOME Bugzilla – Bug 644508
Implement "order-changed" signal
Last modified: 2021-06-10 11:25:56 UTC
ATK exposes the accessible object in a container-like tree. Some of the basic methods are: atk_object_ref_accessible_child (container, index) atk_object_get_index_in_parent And some relevant signals: "children-changed" (with the "add" and "remove" container) Unless the container has the state ATK_STATE_MANAGES_DESCENDANTS, once the AT gets the child, it would suppose that the index will be constant. But in some containers, it would be possible a kind of sort (ie: a list with items sorted by name, and then the user wants then to be sorted by date). In this case, the index that the AT are managing became wrong. Right now there are no way to expose that the index is wrong (unless the sort is implemented by removing and re-adding the objects). A way to solve that could be add a "order-changed" signal: void user_function (AtkObject *atkobject, gpointer user_data) The "order-changed" signal is emitted when the index of any of the children of #atobject has changed. That means that any client that got a child calling atk_object_ref_accessible_child with a specific index, now could get a different child using the same child atkobject : the object which received the signal. user_data : user data set when the signal handler was connected. PS: after a quick chat with Joanmarie, although he said that the signal makes sense, right now it is not required on Orca. This is the reason Im setting a lower priority.
As a related aside, there does seem to be: * object:row-reordered * object:column-reordered While those are not what applies here, the general scenario seems quite similar. Thus if such a new signal is deemed worthwhile, I would want to take a closer look at these table-related signals: * Are three really needed? Or should a more general signal be provided along with a means by which one could identify what got reordered? * If all three are indeed needed, fine. But should we bring the new signal into alignment with the existing ones? And/or is there stuff we'd like to change about them? (I have no opinions yet. Merely jotting this down while I'm thinking about it.)
If we're actually thinking of addding an "order-changed" signal, I wonder whether it would make sense to add a _required_ parameter to the callback signature so whenever that signal gets emitted, you always attach a "new order" along with it, in a similar way as its done with GtkTreeModel's 'rows-reordered' signal [1]. So, the callback for that signal, as I'm envisioning it right now, would be something like this: void user_function (AtkObject *atkobject, gpointer new_order, gpointer user_data) Where, wildly stealing text from [1], the description of "new_order" would be: "new_order : an array of integers mapping the current position of each child to its old position before the re-ordering, i.e. new_order[newpos] = oldpos." This would be basically like sending the "old" and "new" values for a property, but in this case such a property would be the order itself. And I guess that it could be useful for ORCA (as yet-another "view" of the "model" that is the content in the running application) to know not only that the order has changed but also how it has changed. My 2 cents, Mario [1] http://developer.gnome.org/gtk/unstable/GtkTreeModel.html#GtkTreeModel-rows-reordered
ATK Hackfest 2011 conclusion: it seems that it would be interesting to have this signal, for example, in order to ensure that cache is updated if you are implementing a container without the state ATK_STATE_MANAGES_DESCENDANTS At first it would be good to add it. Check comment 2 with some additional ideas on this signal.
[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.]
I want to understand how receiving this signal will have a practical difference from receiving "children-changed"
(In reply to comment #5) > I want to understand how receiving this signal will have a practical difference > from receiving "children-changed" children-changed are used to notify that you added or removed a children. The idea of this signal would be used if you change the order (ie: a list initially by alphabetical order, changed to order by date). This could be simulated by children-changed signals, but would require a children-changed signal per child. With order-changed you just emit a signal (and probably providing a array with the new order like Mario said on comment 2). Anyway, as I said on comment 3, this signal is not a really priority thing.
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.