Hi All, As discussed on the meeting today I would like to propose an API addition to ATK.
Rationale: the current "text-changed" signal (that includes text-changed::insert and text-changed::delete) in Atk includes only the offset and the length of the text insert/removed. The mapped at-spi event includes the inserted/deleted text, so the bridge needs to get that text. For atk implementations that fires the event async (like Gecko 2.0 of Java) the actual text has been already changed when the bridge queries that text. Proposal: Add 3 new signals "text-insert", "text-remove" and "text-update" including offset, lenght and text params. We would mark as deprecated the old "text-changed" signal. Impact: We won't break API or ABI. The bridge would need to be updated to handle these new signals, and map to the proper at-spi events (I think we don't have text-update on at-spi). AT applications wouldn't need to be changed and would get at-spi text-changed event with proper details. Atk Implementations could switch from the old signal to the new if they require the newest Atk version including those signals, or can have code to deal with different atk versions on runtime (query if the new signals are available). Another API change that I would like to propose is related to text-selection::changed as currently it does not include start nor end offset, so we could have in a similar way text-selection-added, text-selection-removed and text-selection-updated, including the selection number, start and end offsets as parameters. So what do you think? Any other additions we may want to have for GNOME 3 before the API freeze? Of course as discussed during the meeting we should try to do a more deep API update for gtk4 (this time breaking things!). Thanks! Salu2 _______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
