Re: [g-a-devel] About the signal "text-update"

[Alexander Surkov <surkov alexander gmail com>]

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 <apinheiro 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