Hi all,
I'm currently trying to add support for AtkHypertext, AtkHyperlink and
AtkHyperlinkImpl in WebKitGTK and I found the following function
confusing:
gint atk_hypertext_get_link_index (AtkHypertext *hypertext,
gint char_index);
According to the docume
On Tue, 2010-09-28 at 14:49 -0400, Joanmarie Diggs wrote:
> [...]
> > ..but still, I can't get what the char_index is and what it's used for.
>
> Consider this paragraph:
>
> This is a test.
>
> char_index refers to the offset within the string, thus:
>
> T h i s i s a t e s t .
> 0 1
Hi,
On 09/29/2011 12:29 PM, Javier Hernández Antúnez wrote:
> [...]
> You're not the one, Mario Sánchez reported to me another problem with a
> probably related issue, so,
Well, my problem seems not to be actually the same one. In my case this
is the trace I get:
"""
/opt/gnome3/lib64/python2.7/
Hi again,
On 09/29/2011 08:29 PM, Mario Sanchez Prada wrote:
> [...]
> For some reason, it starts (apparently correctly) using the GObject
> python bindings from /opt/gnome3 (where I install everything from my
> jhbuild) but then it bails out of the jail and moves into
> /usr/lib6
Hi,
I recently found out that the text displayed in instances of GtkEntry
with 'visibility' set to FALSE (meant to be used for passwords mainly)
is not being exposed at all to Assistive Technologies like Orca, which
are always getting and empty string, due to code snippets like this one
in gtkentr
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 e
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
> [...]
> 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
> [...]
> 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
> 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 o
Hi all,
Pineiro and me have been holding an interesting conversation about
this in the a11y BoF in GUADEC and we believe we have found a better
way to move forward here, which would mean not having to deprecate
individual elements of an enum nor breaking the ABI at all, while
still allowing us to
Hi,
> [...]
> 2. Add a new function that will only need the offset and the
> granularity as input parameters:
>
> gchar* atk_text_get_text_for_offset (AtkText *text,
> [...]
Just to mention that after some discussion on bugzilla (see [1]), we are
thinking that perhaps a better name for this
Hi all,
I know I‘m late to the discussion, but I would like to show my support for
expanding the AtkValue interface. Furthermore, it’s not the first time I found
a situation where having a more complete version of the AtkValue interface
would be handy (see [1] and [2]), and this element seems l
14 matches
Mail list logo
