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



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]