On 08/19/2013 04:18 PM, Alexander Surkov wrote: > I think I'm fine if we had text-inserted/removed only. At least it > seems I don't have an objection to keep it alive. > Alex.
Thanks for the clarification. FWIW, I have just removed 'text-update', and I'm working on next atk release. ATK 2.9.4 will not include that signal. So I think that we can conclude that this thread is over. Again, thanks for all the feedback (to Alex and to everyone) Best regards > > On Wed, Aug 14, 2013 at 10:27 AM, Piñeiro <apinhe...@igalia.com> wrote: >> On 08/13/2013 08:10 PM, Alexander Surkov wrote: >>>> 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. >> Ok, now I start to understand things. One of the reasons I didn't know >> how that signal was intended to use is because the parameters of that >> signal are defined with the following types: >> 4, G_TYPE_INT, G_TYPE_INT, G_TYPE_INT, G_TYPE_STRING >> >> So taking into account your comment, there are was an error when the >> update-text was created. And the arguments should be: >> * arg1 (int): offset for the change >> * arg2 (int): size of removed text >> * arg3 (string): removed text >> * arg4 (int): size of added text >> * arg5 (string): added text >> >> Or if we have null terminated strings, we could forget the size of >> removed/added texts, and just have three arguments. >> >> Taking into account that the signal is not used anywhere, it shouldn't >> be a problem to fix the wrong arguments (Note: we will not break ABI, as >> we wisely didn't add a default virtual handler for that signal). >> >>>>> 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. >> Well, text-inserted/text-removed are already introduced at ATK, and used >> at at-spi. As you say things seems to work fine right now. So for the >> same "fix update-text signal would not be a big deal" I mentioned >> before, I'm also tempted to just remove that signal (without >> deprecation) because what we have now works, and is what is being used. >> IMHO, keeping all the three can be a source of confusion. >> >> Anyone against removing 'text-update' signal? >> >> Again, thanks for the feedback >> >> BR >> >> -- >> 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
