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