Hey. Answering inline. On Tue, Aug 13, 2013 at 7:31 AM, Piñeiro <apinhe...@igalia.com> wrote: > 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.
Right :) I have a mix of ATK and IA2 in my head so what I said above makes sense for IA2 since it has three event types. > 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? As Joanie said, text updated event includes an offset, removed and inserted texts. If it's single insertion then removed text is empty and vise versa. >> 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. It seems the world lives just fine without text_udpated events so you might want to introduce text_inserted/text_removed only in ATK and that will be a working approach. Thanks! Alex. > >> 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
