Re: Module Proposal: GNOME Shell

[Owen Taylor <otaylor redhat com>]

On Wed, 2010-03-31 at 09:28 -0400, Willie Walker wrote:
> Hi Owen:
> 
> Many thanks to the GNOME Shell team for writing this and the WIKI page.  It is very promising to
>see accessibility included in the roadmap.  I have a few questions:
> 
> 1) I believe accessibility should be a requirement for GNOME Shell for GNOME 3.  Does the
> presence of it in the roadmap mean there is a commitment to making
this so?

The roadmap includes both items that I think are essential for GNOME 3
and items that I just think are very important for GNOME 3.

I don't think we should ever believe that it's enough to have
accessibility that is there as a bullet point, or to have accessibility
that someone who is extraordinarily motivated can "suffer through". In
my mind accessibility has to be held to the same high standards as
everything else in GNOME - that means that developers are actively
testing their applications against it, that it can be on by default
without introducing huge performance or stability problems, that it has
a clear and easy to use configuration system, that we've thought through
user experience, and  as much as possible, it just works.

Getting accessibility fully to that standard isn't going to happen for
GNOME 3.0... we've never been there for GNOME 2, we aren't going to be
there in 4-5 months even if it was the only thing we worked on.

But where I definitely want to be for GNOME 3.0 - in the next 4-5 months
is to make sure we've laid the groundwork properly so that we can get
there in follow-on releases, both on a technical level and on a
user-experience level. 

At a technical level, once he finishes up his current immediate work on
the message tray Dan Winship is going to dedicate a chunk of time
(probably around a month or so) to pushing things forward. What exactly
he works is going to depend on further investigation, but I would
imagine he'll do is work with the Clutter and Ca11y folks to figure out
a solid Clutter+ATK story (is ca11y something separate, should it be
integrated into Clutter, if it's separate, how do the modules get
loaded, etc), then figure out how that fits in with the GNOME Shell
toolkit and the ways that we build our user interface. Because
individually making clutter actors accessible isn't going to produce a
comprehensible, useful screen read of the shell.

And I think if we get the technical foundations right, that will also
(roughly) get us back to 3.0 to the status quo of having something that
someone who is sufficiently motivated can work with. I'm also hoping
that if the technical foundations are settled it should be possible for
a broader range of contributors to jump in and make small fixes to
improve things... to add missing roles, etc.

Separately, I've turned the job of working with Joseph to get his
magnification patches landed over to Colin, since I was completely
failing to get it done. Colin did a review of the latest patches last
week, and I expect that to move forward pretty quickly now.

Keynav is probably the place where we need the most help and the
immediate help we need is on the keynav design. To give a taste of the
questions:

 - Can the current 'search-based' keynav be extended to be complete
   or we need an alternate "navigation" design that more literally
   maps to mouse actions?

 - If we need a navigation design, what specific keys are used to 
   trigger navigation and to navigate and to activate actions?

Basically, we need to come up with a complete specification for how
keynav works before we can proceed to the subsequent steps of figuring
out the necessary infrastructure and implementing it. At this point, I
don't see that all coming together prior to GNOME 3.0, but there is
going to be *some* keynav there - all the current Metacity keynav still
works, a lot of functionality is accessible by search. What is more at
risk is completeness - making sure that *all* functionality is
accessible.

> 2) In the "Appearance" section on the WIKI, there is mention of theming. 
> Will this hook into the desktop appearance settings we have available
> in GNOME today?

In the roadmap, what I meant by "theme" was really more in terms of
"overall appearance" rather than "alternate overall appearance". Because
every single bit of the shell appearance is driven out of CSS
stylesheets, there is great possibility for configurable theming, but
because every single bit of the shell appearance is driven out of CSS
stylesheets, there is also a great interdependence with the code, and
possibility for themes to break as the code is developed.

For that reason I'm not crazy about the idea of allowing users to
install new themes and have them picked in appearance properties for
this development cycle. But if there's someone who's willing to do
maintenance, I think we could definitely have "hacks" like loading an
additional stylesheet if the GTK+ theme name has specific recognized
name like "HighContrast".

We certainly will be following the preferences for font and font size
prior to 3.0.

- Owen