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 _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
