Autopilot-gtk must not use memory addresses as object ids

[Thomi Richards]

The fact that autopilot-gtk is using object memory address locations as object ids is causing problems with server-side parameter matching, where values outside MININT <-> MAXINT overflow the xpathselect rule.

[Martin Pitt (pitti)]

I don't understand that -- refreshing properties of a GObject doesn't change the address of the GObject itself. That would only happen if you destroy e. g. a button and re-create it?

[Martin Pitt (pitti)]

Ah, I understand now. AFAICS, the easiest option is to just use the
lower 32 bits. This ought to work in practice as the heap is in a
single virtual segment anyway, so as long as we don't create many
hundred million widgets (which we couldn't handle anyway, FWIW) there
should be no collisions.

The alternative would be to use an increasing number like in -Qt.
When I previously wrote "there are no dynamic properties" I forgot
about qdata, which provides something like that. They are not type
save or introspectable, but that isn't necessary. Something like

  GQuark OBJ_ID = g_quark_from_static_string("AUTOPILOT_OBJECT_ID");
  static guint32 cur_obj_id = 1;

in the ap initialization, and then

  g_object_set_qdata (my_widget, OBJ_ID, (gpointer) cur_obj_id++);

  [...]

  guint32 id = (guint32) g_object_get_qdata (my_widget, OBJ_ID);

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:autopilot-gtk at revision 53, scheduled for release in autopilot-gtk, milestone Unknown