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

[Willie Walker <William Walker Sun COM>]

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,

Will

Piñeiro wrote:
> 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
> [2]).
>
> 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
>
> [1] http://people.igalia.com/apinheiro/files/cally_guadec_2009_slides.pdf.gz
> [2] https://bugs.webkit.org/show_bug.cgi?id=25897
> [3] http://maemo.gitorious.org/fremantle-hildon-desktop
> [4] http://maemo.gitorious.org/fremantle-hildon-desktop/hildon-desktop/blobs/master/src/a11y/launcher/hda-launcher-page.c
>
> ===
> API (apinheiro igalia com)