Re: [g-a-devel] RFC: AtkText simplification

[Mario Sanchez Prada <msanchez gnome org>]

Hi,

Sorry for the *so* late reply, but I'm suscribed to this mailing from my
personal mail only and haven't checked this mailing list until now.

On Sat, 2013-04-13 at 15:09 -0400, Joanmarie Diggs wrote:
[...]
> So I am here to propose we simplify AtkText and do it *now* i.e. while
> we are very early in the GNOME cycle. In particular, I would like to
> suggest for your consideration the following two changes:
>
> 1. Deprecate atk_text_get_text_{before,after}_offset()
> 2. Deprecate the TEXT_BOUNDARY_FOO_{START,END}

Interesting... since this things are a source of major pain in the
rewriting I'm currently doing in WebKitGTK+ to avoid using pango and
gail.

> In the first case, clients such as Orca would use (through AT-SPI2)
> atk_text_get_text_at_offset(). If the text before or after a given
> offset were desired, clients would make a second call having gotten the
> needed offset from the first call.


As an implementor, it makes me extremely happy to know that after and
before variants are not that necessary after all.

> In the second case, clients such as Orca would use (through AT-SPI2) a
> brand new set of TEXT_BOUNDARY_FOO boundaries. My guess is that we'd
> want it to mimic the behavior of the current START results, but that
> will require some investigation to be sure.

I also think that mimic the START boundaries is probably the way to go,
since it's the most natural one, IMHO (at least if I think of
Left-To-Right languages)

> In order to facilitate this simplification getting under way, I will
> remove Orca's use of atk_text_get_text_{before,after}_offset().

\o/

So, let me get this straight... does this mean I do not have to
implement the after/before variants AT ALL in WebKitGTK+ and that I only
have to consider the START boundary?

Because if it was like that, I would say things could happen way faster
in WebKitGTK+ land... maybe even during the next 2 weeks... :)

Thanks,
Mario