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

[Alexander Surkov <surkov alexander gmail com>]

Hey. Answering inline.

On Tue, Aug 13, 2013 at 7:31 AM, Piñeiro <apinheiro 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 <apinheiro 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