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

[Piñeiro <apinheiro igalia com>]

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.

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?

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

> 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