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

From: Owen Taylor <otaylor redhat com>

>  Accessibility:
>   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]