After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 644508 - Implement "order-changed" signal
Implement "order-changed" signal
Status: RESOLVED OBSOLETE
Product: atk
Classification: Platform
Component: atk
unspecified
Other Linux
: Normal minor
: ---
Assigned To: ATK maintainer(s)
ATK maintainer(s)
Depends on:
Blocks: 638537
 
 
Reported: 2011-03-11 15:35 UTC by Alejandro Piñeiro Iglesias (IRC: infapi00)
Modified: 2021-06-10 11:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alejandro Piñeiro Iglesias (IRC: infapi00) 2011-03-11 15:35:39 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.
Comment 1 Joanmarie Diggs (IRC: joanie) 2011-03-11 16:06:43 UTC
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.)
Comment 2 Mario Sánchez Prada 2011-05-11 09:07:56 UTC
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
Comment 3 Alejandro Piñeiro Iglesias (IRC: infapi00) 2011-05-11 09:12:02 UTC
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.
Comment 4 André Klapper 2011-06-23 22:06:29 UTC
[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.]
Comment 5 David Bolter 2012-01-23 15:14:28 UTC
I want to understand how receiving this signal will have a practical difference from receiving "children-changed"
Comment 6 Alejandro Piñeiro Iglesias (IRC: infapi00) 2012-01-23 18:03:45 UTC
(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.
Comment 7 André Klapper 2021-06-10 11:25:56 UTC
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.