Re: Caribou: suggestion of some features

Hi, Piñeiro, Mats, and all

Thank you for your agreement and constructive advice.

> I personally agree that both are interesting. My advice is create two
> new bugs on GNOME bugzilla. I skimmed the current list of Caribou bugs
> [1] and I didn't see your suggestions. I think that it is worth to
> open two new bugs.
I created two bugs on GNOME bugzilla.
Bug 636208: https://bugzilla.gnome.org/show_bug.cgi?id=636208
Bug 636209: https://bugzilla.gnome.org/show_bug.cgi?id=636209

Please add comments on them.

Thank you.

--

-- 
Jiro Matsuzawa
PGP Key ID: 0xECC442E9
PGP Key Fingerprint: E086 C14A 869F BB0E 3541 19EB E370 B08B ECC4 42E9

Accessibility in Google Chrome

_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

Re: Accessibility in Google Chrome

From: Mihail Claudiu <professor_khaos_klaus_mk <at> yahoo.com>

> I've been trying to get the URL bar control from Google Chrome in order to get 
> the URL text. So far I've managed to get the chrome window using at-spi and 
> iterate through all the control hierarchy. I can see which one is the URL text 
> as for every AccessibleEditableText control I simply print out the text (and 
> identify which is link). The problem is that most of the chrome controls have a 
> NULL name and description as provided by Accessible_getName and 
> Accessible_getDescription. Thus, I have no apperent way to uniquely identify the 
> URL bar from withing the program so I can programatically access the URL.
> 
> Does anybody, please, have any suggestions on this?

As far as I know Chrome doesn't have accessibility support from the
ATK point of view.

You can take a look to this bug [1], reported on Chromium (as Chrome
uses the code from Chromium)

[1] http://code.google.com/p/chromium/issues/detail?id=24585

BR

===
API (apinheiro <at> igalia.com)

Re: Accessibility in Google Chrome

_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

Re: Accessibility in Google Chrome

From: Claudiu Mihail <claudiu.bogdan.mihail <at> gmail.com>

> Thank you for the reply.
> 
> I looked at the bug. What I can tell is that chromium hasn't the right
> kind of support for atk (or at-spi, what I'm using). Would that
> explain why the names and descriptions don't show up?

Yes, that would explain that, but I can't ensure it 100%. I would need
to check that.

> Also I forgot to mention that inspecting chromium with gtkparasite
> yields the names of the widgets chormium has (including the URL bar).
> How would I be able to get the same results?

Well, as I said I didn't check it really deep, but AFAIK, chromium is
using GTK for some parts. I suppose they use GTK for the menu(s),
etc. But the html engine uses WebKit (not sure which port). If this
URL is drawn using the html engine, that would explain why this bar
doesn't have support but other parts yes.

As I said on the bug [1], right now there are a effort to improve the
ATK support on the WebKitGTK port. In fact, some months ago, epiphany
(a WebKitGtk based web browser) was in a similar status. It uses GTK
for the menus, so you were able to get information from it, but as it
was not present ATK support for WebKitGTK you couldn't get anything
drawn by the html engine. Now things are in a better status ;)

BR

[1] http://code.google.com/p/chromium/issues/detail?id=24585#c6

===
API (apinheiro <at> igalia.com)

Fw: Minutes of the GTK+ Team Meeting - 2010-12-14

FYI

From: Matthias Clasen <matthias.clasen <at> gmail.com>
Subject: Re: Minutes of the GTK+ Team Meeting - 2010-12-14
Date: 2010-12-15 13:20:28 GMT

2010/12/15 Piñeiro <apinheiro <at> igalia.com>:
>
> Are this treeview refactoring mostly internal, or are there specific
> API changes? After this refactoring it would be required to be
> modified the apps using GtkTreeView?
>
> Anyway I was also thinking on GailTreeView, the object that provides
> the accessibility support for GtkTreeView. Should gailtreeview work
> after all these changes?

It is mostly internal refactoring, public api should be largely unchanged.
Very possible that gail needs adjustments / enhancements for the new
possibilities, though.

_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

ATK API addition + deprecation

Hi All,

As discussed on the meeting today I would like to propose an API
addition to ATK.

Rationale: the current "text-changed" signal (that includes
text-changed::insert and text-changed::delete)  in Atk includes only
the offset and the length of the text insert/removed. The mapped
at-spi event includes the inserted/deleted text, so the bridge needs
to get that text. For atk implementations that fires the event async
(like Gecko 2.0 of Java) the actual text has been already changed when
the bridge queries that text.

Proposal: Add 3 new signals "text-insert", "text-remove" and
"text-update" including offset, lenght and text params. We would mark
as deprecated the old "text-changed" signal.

Impact: We won't break API or ABI. The bridge would need to be updated
to handle these new signals, and map to the proper at-spi events (I
think we don't have text-update on at-spi). AT applications wouldn't
need to be changed and would get at-spi text-changed event with proper
details. Atk Implementations could switch from the old signal to the
new if they require the newest Atk version including those signals, or
can have code to deal with different atk versions on runtime (query if
the new signals are available).

Another API change that I would like to propose is related to
text-selection::changed as currently it does not include start nor end
offset, so we could have in a similar way text-selection-added,
text-selection-removed and text-selection-updated, including the
selection number, start and end offsets as parameters.

So what do you think?

Any other additions we may want to have for GNOME 3 before the API freeze?

Of course as discussed during the meeting we should try to do a more
deep API update for gtk4 (this time breaking things!).

Thanks!

Salu2

Re: ATK API addition + deprecation

From: Fernando Herrera <fherrera <at> onirica.com>

> Rationale: the current "text-changed" signal (that includes
> text-changed::insert and text-changed::delete)  in Atk includes only
> the offset and the length of the text insert/removed. The mapped
> at-spi event includes the inserted/deleted text, so the bridge needs
> to get that text. For atk implementations that fires the event async
> (like Gecko 2.0 of Java) the actual text has been already changed when
> the bridge queries that text.

And in the case of sync events, you need to be really careful, and
emit the events in the proper moment, that can be different on the
insert and on the delete, so the AT tool could obtain the proper text
inserted or deleted. This add confusion to the code and IMHO, it is
error prone.

> Proposal: Add 3 new signals "text-insert", "text-remove" and
> "text-update" including offset, lenght and text params. We would mark
> as deprecated the old "text-changed" signal.

Could you ellaborate this "text-update"? With the current wisdom,
AFAIK, if you update a text, is the same that emit a remove and a
insert signal.

BR

[1] http://bugzilla.openedhand.com/show_bug.cgi?id=1841
[2] http://bugzilla.openedhand.com/show_bug.cgi?id=1894

===
API (apinheiro <at> igalia.com)

ANNOUNCE: AT-SPI2 1.91.4 released

AT-SPI2 1.91.4 is now available for download at:

http://download.gnome.org/sources/pyatspi/1.91/
http://download.gnome.org/sources/at-spi2-core/1.91/
http://download.gnome.org/sources/at-spi2-atk/1.91/

Notes
=====

A list of work required before the full release can be found at:

http://www.a11y.org/atspi-todo

What's changed in AT-SPI2 1.91.4
===============================

* Many bug fixes.  I would consider the code to be beta-quality again.

* Merged support for direct dbus connections between apps and ATs.  This
   greatly improves performance but is only compiled in for
   at-spi2-atk if dbus-glib 0.90 is available because of FDO#30574.

* Added a gsettings schema to specify the location of libatk-bridge.so.
   This may be useful to non-GTK applications and toolkits that want to load it.

What is AT-SPI2
===============

AT-SPI2 is a D-Bus based accessibility framework. It defines a D-Bus
protocol for providing and accessing application accessibility
information. The project includes a library for bridging the D-Bus
protocol to the ATK API, allowing Gtk based applications to be made
accessible. It also contains a client (AT) side library in Python.

Where can I get more information about AT-SPI2
==============================================

The project wiki is available at:

http://www.a11y.org/d-bus

How can I contribute to AT-SPI2?
================================

We are actively seeking contributors to help us make this the standard
a11y framework for Gnome. We need help testing with Gnome accessibility
technologies, improving performance, and generally tying up loose ends.
The above-referenced page contains a list of known issues that should be
fixed.

IRC   : #a11y on Gimpnet
E-Mail: accessibility-atspi <at> lists.linux-foundation.org

Development repositories can be found at:

git://git.gnome.org/pyatspi2
git://git.gnome.org/at-spi2-core
git://git.gnome.org/at-spi2-atk

Review small tasks suitable for student competition

Project:Possibility [1] organise the SS12 [2] coding competitions to
get students working on and excited about open source accessibility
projects. The students hack over a weekend and are judged. This year
there are 3 competitions with the finals at the CSUN conference [3],
which GNOME are attending for the second year. We're excited to say
CSUN are also running in the competitions this year.

Last year we had 2 teams working on Caribou features [4]. This
introduced the students to working with a real open source project. It
also got some awesome student energy focussed on adding features into
a GNOME a11y project. We'd like to do more of this for the next round,
but we need good weekend hacking project ideas and mentors.

So the ask is that everyone review and update the small task wiki page
[5] and add more ideas. For example the Caribou task to add skinning
was recently patched by Eitan, The idea could perhaps now be updated
to build cool features into Caribou based on this work? API already
suggested Accerciser bug fixes and new plugins. So any cool ideas
plugin ideas are most welcome, but bug fixes might not work so well in
a competition unless careful chosen.

We also need mentors willing to be guide the students before, during
and after the SS12 event. Last year Ben Konrath did a fantastic job
and the students were issued certificates for contribution to GNOME by
Stormy. So is anyone interested in mentoring next year?

Bryen is joining us in the Project:Possibility board meeting on 07/01
to discuss this and it would be great to have more ideas or mentors by
then.

1: http://www.projectpossibility.org
2: http://ss12.info/
3: http://http://csunconference.org/index.cfm
4: http://live.gnome.org/Caribou
5: http://live.gnome.org/Accessibility/GetInvolved/SmallTasks

--

-- 
Steve Lee

Full Measure - open source accessibility - http://fullmeasure.co.uk