Re: GNOME3 reality check

[Owen Taylor <otaylor redhat com>]

Thanks for starting this discussion Matthias. Do we have an idea of how
we are going to track these major items? A tracker bug? A wiki page?

at least a basic implementation of 'finding and reminding'
==========================================================

I'd really like to have this for GNOME 3. But I'm not sure it's a
blocker - it's not a regression from GNOME 2 if we just offer recent
documents.

Right now, there really isn't a start on it. I was hoping to spend a
week or two on it personally and bootstrap it to the point where
incremental contributions were easier. But just staying ahead of patches
is pretty hard for me at this point.

"seamless fallback to panel/metacity in 'hw sucks' situations"
==============================================================

There are some limits to what we can do here automatically without
knowing anything about the driver situation on the system. The basic
problem is that there are all sorts of suck:
 
 * No GL at all. This typically only happens if a system is
   misconfigured.

 * Only software GL. This one is easy to detect. We have code in
   the Fedora desktop-effects tool, etc.

 * GL that isn't featureful enough. (Tiny texture size limits, no
   texture-from-pixmap, etc.) Possible to detect with more work, but
   largely a fringe case.

 * Buggy GL. This isn't possible to detect. Except for the case where
   all GL programs crash. For that reason, we probably don't want
   gnome-session to directly try and do any GL detection; better to
   use a helper binary.

 * Horribly slow hardware GL. We could theoretically develop some sort
   of benchmark, but it's a tricky area. And how slow is too slow?

Components of a solution:

 * Tool for switching. My idea earlier was to strip the Fedora-specific
   Compiz bits out of desktop-effects and reuse the rest of the code
   there. Could be packaged with gnome-shell or gnome-control-center.

   Needs development of terminology/text.

 * Way of detecting the need for a fallback upfront. Probably a binary
   that detects presence of hardware GL, and applies some sort of
   distro supplied whitelist/blacklist to the OpenGL renderer string.

 * User experience for logging in and getting a fallback. My idea here
   is that the experience is that you should get a one time dialog
   that switches your config setting.

 * Way of detecting the need for a fallback after the fact? Not sure
   if we can do this well enough to be worthwhile.

 * Way of switching without being able to log in - hold down a key
   while logging in or whatever?

system status / notifications separation, symbolic icons
working message tray / telepathy integration
============================================

Not too worried about this one. There's a ton of work going on - Marina
is on this full time, working with a summer of code student, and we've
recently had somoeone else (Giovanni Campagna) show up and start
flooding us with patches.

basic shell a11y and magnifier integration
==========================================

Magnifier seems in good shape. With a few days to implement some of the
mockups for the config, we'll have something that's *vastly* better than
gnome-mag.

Keynav is pretty well in hand... Dan Winship is working on that, and has
patches for a lot of it already.

In terms of the rest - I don't have a worry about getting a framework
for accessing Clutter hierarchies through AT-SPI. In terms of turning
that into a functional desktop that can be used by the visually impaired
with a screen-reader... seems unlikely to me. But maybe the "check box"
is good enough.

Other stuff
===========

App integration: we need to publish guidelines for GNOME 3 apps for
  system status area (or not!), notification, and the application
  menu, and then make sure all "apps" that ship with the GNOME
  release meet them.

Appearance: I think we definitely need a new window manager theme
  that integrates with the shell.