On 06/26/2013 02:40 PM, Mario Sanchez Prada wrote:
>> On 06/24/2013 02:26 PM, Mario Sanchez Prada wrote:
[...]
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 imple
> On 06/24/2013 02:26 PM, Mario Sanchez Prada wrote:
> >> [...]
> >> 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?
Yes, that would b
On 06/24/2013 02:26 PM, Mario Sanchez Prada wrote:
>> [...]
>> 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
On 06/24/2013 01:51 PM, Trevor Saunders wrote:
>> 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,
>>
> [...]
> 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
> 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
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'
> [...]
> 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
> [...]
> 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
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
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
-
> From: gnome-accessibility-devel [mailto:gnome-accessibility-devel-
> boun...@gnome.org] On Behalf Of Joanmarie Diggs
> Sent: 22 June 2013 19:49
> To: gnome-accessibility-devel@gnome.org
> Subject: Re: [g-a-devel] RFC: AtkText simplification (take 2)
>
> On 06/17/2013 0
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 first step, and probably
> the only thing that we can do o
13 matches
Mail list logo
