On 08/12/2013 08:13 PM, Alexander Surkov wrote: > Hi. The idea of text_update event is a substitution of > text_removed/text_inserted events pair. Are you sure about this?
Reading the original proposal from Fer: https://mail.gnome.org/archives/gnome-accessibility-devel/2010-December/msg00007.html The reason to add new signals was include on them the text that was added/removed, because at-spi was already including that, so needed to ask, and at that moment it was not available. In the same way, I find somewhat estrange to propose three new signals, with the intention of deprecate two of them soon. In the same way, not sure if update-text would be enough. Right now the signal has three parameters. And as they were not documented (sigh) I assume that is something like this: update-text * arg1: offset where the text change * arg2: size * arg3: no idea (anyone?) * arg4: previous text But for example, AFAIK, one of the things that Orca does is expose the text removed when the user press backspace. I see that easily supported with 'text-remove'. How that could be supported with 'text-updated'? Joanmarie, any idea? > It's about less events and > describes better what the user does. So if the user selected the text > and typed new text then it's a case for text_update event. But doesn't cover too well the use case I mentioned before. And if in the end we keep needing 'text-insert' and 'text-remove', having 'text-update' seems like an overkill. And confusing, as implementors would need to decide when use one or the other. > We never > implemented it in Firefox because AT didn't implemented it, we can't > proceed it without AT since it's not backward compatible approach. Well, I thought that was the opposite. First atk+at-spi give the support, implementors use them, and at last AT can start to use it ;) In any case, I prefer to talk first about the meaning and use case of that signal before going to how the AT could use it. > Thank you. Thanks to you, for your quick answer. > Alex. > > On Mon, Aug 12, 2013 at 1:58 PM, Piñeiro <apinhe...@igalia.com> wrote: >> Hi everybody, >> >> I'm right now doing some cleaning at the documentation of atk (as a >> result of doing some long-waited deprecations). As you can recall from >> the atk-hackfest of 2012 [1], one of the conclusions was adding some new >> signals [2] in order to deprecate AtkText::text-changed [3]. And the >> signals text-insert, text-remove and text-update was added with that bug >> [2]. >> >> But, the patch didn't add any documentation at all for those methods. >> And although I was able to infer the meaning (and more important, the >> parameters) of 'text-insert' and 'text-remove" from Fernando >> announcement [4] and the code itself (at-spi2-atk+firefox), I was not >> able to do the same for 'text-update'. Additionaly, and as I said some >> years ago [5], I'm not sure about needing that method. >> >> And, in fact, right now, that signal is not used at all on at-spi2-atk, >> and is not emitted by firefox (that was the first application >> implementing the other two methods). >> >> So, I'm tempted to just mark that signal as deprecated (without >> replacement), unless someone remember the meaning of that signal, or why >> it was created. >> >> BR >> >> [1] https://wiki.gnome.org/Accessibility/Hackfests/ATK2012 >> [2] https://bugzilla.gnome.org/show_bug.cgi?id=638377 >> [3] https://bugzilla.gnome.org/show_bug.cgi?id=653291 >> [4] >> https://mail.gnome.org/archives/gnome-accessibility-devel/2010-December/msg00007.html >> [5] >> https://mail.gnome.org/archives/gnome-accessibility-devel/2010-December/msg00008.html >> >> -- >> Alejandro Piņeiro Iglesias >> -- Alejandro Piñeiro Iglesias _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
