Re: Request for comment (GNOME Shell team): release date for GNOME 3.0

Thanks API!

I think focusing on GNOME Shell a11y via AT-SPI is a great goal to focus on rather than puzzling over general clutter a11y. The end result will be that at least a very specific needed problem will get solved, and perhaps a more general solution will be created in the process.

My understanding is that the Shell Toolkit (ST) used by GNOME Shell is an NBTK fork and is probably the place where AT-SPI/ATK widget work might live. If you were to look into this space and give us an evaluation of the work necessary to make ST accessible, it would be awesome.

Thanks again,


Piñeiro wrote:
From: Owen Taylor <otaylor redhat com>


  Two big areas of work here: one is keynav, the second is exposing
  the user interface tree to AT's. Keynav is partially there, but
  there's a ton of work to make sure that *everything* is keynavigable.

Anyway, the key navigation, after read some mails in the mailing
lists, and some comments in the bugzilla, it is not just a
specific-a11y request, but something that most of the users could
benefit from.

  Exposing the UI tree will likely fall out of the work that is being
  done with Cally, though the exact relationship of that with Clutter
(is it a separate library) is not, to my knowledge, completely finalized.

No, it is not completely finalized (it is any library completely
finalized?), but the talk with Joan Marie help me to prioritize the
missing features to implement.

  But exposing a raw tree of clutter actors is in no way
  interesting, so there's probably considerably *more* work to make
  sure that the tree exposed from gnome-shell meaningful represents
  the objects and actions on them, and likely some AT-side to work to
  figure out how to interact with objects in gnome-shell that had no
  correspondence in the GNOME 2 desktop, like the Overview itself.

The fact that all clutter objects are exposed is a issue detected
since the first time that I saw the full tree (ie: has sense from the
a11y POV to expose a ClutterBehaviour?), and commented on my GUADEC
talk [1]. One option could be implement a way to "hide" the objects
that you don't require, like Webkit folks are doing right now (ie

Anyway, this is not in my list of priorities. AT applications were
making this kind of filtering for a long time (if you see a tree
hierarchy of objects with glade in a GTK+ aplication, you would see
that you don't need to navigate or interact with all the objects, the
container hierarchy, etc.).

Right now, I think that the priority is get ORCA interacting with the
GNOME-shell, at least in basic way.

  (Editorial: unfortunately, accessibility in GNOME has too often been
  partial technical solutions and unfulfilled promise. While not
  regressing on the technical side is important, I don't think that's
  the interesting thing - the interesting thing is to make progress
  on the user experience here. So we shouldn't be grading ourself
  on whether we continue exposing a UI tree to AT's, but whether we
  have AT's that can take that information and present a coherent
  user experience based on it.)

Well, I think that it is a two way problem/solution: yes, the AT
applications will require to take the information and present it in a
coherent way, but in order to make that, GNOME-Shell requires to
expose that properly.

A quick example of that, that I can made as recently hildon-desktop
was being public [3], and it is using cally (well using the old name,
but using it).

It has a task launcher that, surprisingly, allows you to launch the
apps. It is basically a grid with several ClutterTexture used as
buttons. In the past this was just a ClutterActor (this was moved to a
ClutterGroup two days ago), and the grid was just a object managed by
it. So, from the AT didn't have any way to get the object, so a custom
a11y object was required to be created [4].

This is just a example, and I can't tell if this will be required, as
I need a deep review GNOME-shell. But in the same way that
hildon-desktop required some work, and the hildon widgets required
HAIL, there is a high possibility of that.

However, I agree that right now the a11y support on gnome-shell
requires more work in the base library (Cally). But, my idea is, after
solve the issues pointed by Joan Marie in the Boston Summit, orient
the development of Cally in a real application, in this case,
gnome-shell, to have a target of evolution, instead of just implement
atk features inside cally without a specific reason.

To finalize: the other problematic thing not commented here is the
Gtk-Clutter integration. I made some questions about that on the
Boston Summit, but I would like to confirm that:

  * Right now there are some Gtk elements on the Gnome-shell (ie: the
    user info panel)
  * The idea is remove that in a future.

I'm right? On my tests with gnome-shell, the gail-cally interaction
gave me some problems. The difference between a mixed clutter-gtk
application and a pure clutter (or gtk) is really important. A mixed
environment have several issues to solve.

Best regards, and sorry for the long mail


API (apinheiro igalia com)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]