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

[Piñeiro <apinheiro igalia com>]

On 08/19/2013 04:18 PM, Alexander Surkov wrote:
> 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.

Thanks for the clarification. FWIW, I have just removed 'text-update',
and I'm working on next atk release. ATK 2.9.4 will not include that signal.

So I think that we can conclude that this thread is over.

Again, thanks for all the feedback (to Alex and to everyone)

Best regards

> 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


-- 
Alejandro Piñeiro Iglesias