Hi,
Sorry for the late reply. I'd just like to explicitly agree with the plan here.
Also, as I plan to continue working on my "removing the dependency on
pango/gail from WebKitGTK+" patch this week, I will take this into account
already by *not* implementing those deprecated methods and boundar
On 06/24/2013 05:06 AM, Mario Sanchez Prada wrote:
> And perhaps it would be even worth it to first post a patch to
> "deprecate" those methods in WebKitGTK+ too, so we are left with just
> the "at" method and the START boundaries, and get that upstream
> before pushing the "no pango" patches, but
On 06/22/2013 08:49 PM, Joanmarie Diggs wrote:
> On 06/17/2013 02:40 PM, Piñeiro wrote:
>
> [...]
>
>> As Joanmarie said on that thread, the idea is not having any _END/_START
>> boundaries, and the "surviving" boundary would mimic what _START is
>> doing right now. Anyway, as I said this is the fi
> [...]
> Since Orca is the only AT which had been -- but is no longer -- using
> those deprecated methods, I'm not entirely sure what difference it
> would make from the point of view of ATs. ;)
Probably none, just double checking :)
> But it's early and Monday, so if I'm missing something (oth
> [...]
> Right now I prefer a). The main problem with b) is that we would have
> three pairs of macros that would mean exactly the same.
I'm sorry to disagree here, but I think b) would be better, all things
considered, and as long as it's clearly stated that all those _START boundaries
are de
On 06/24/2013 12:04 PM, Mario Sanchez Prada wrote:
>> [...]
>> Right now I prefer a). The main problem with b) is that we would have
>> three pairs of macros that would mean exactly the same.
> I'm sorry to disagree here, but I think b) would be better, all things
> considered, and as long as it'
> b) Add the generic boundary now. The enum would be something like:
> typedef enum {
> ATK_TEXT_BOUNDARY_CHAR,
> ATK_TEXT_BOUNDARY_WORD_START,
> ATK_TEXT_BOUNDARY_WORD_END,
> ATK_TEXT_BOUNDARY_SENTENCE_START,
> ATK_TEXT_BOUNDARY_SENTENCE_END,
> ATK_TEXT_BO
> [...]
> So, taking into account that you are already working on this, I assume
> that you would prefer to add the generic boundary now, in order to
> avoid two updates of the implementation of those APIs. Right?
It's not that I prefer to do that now in order to avoid two updates of the
implement
