Module semi-proposal: gnome-shell

[Owen Taylor <otaylor redhat com>]

Oh, the deadline was *last* Monday? Actually, I knew that, but it snuck
up on me, then it took me a few days to figure out what I wanted to say
here...

This should be read as a semi-proposal: at this point I don't think
gnome-shell is going to be ready to be shipped as a final component on
the 2.30 schedule. But getting it into people's hands is important for
having it be ready for GNOME 3.

So what makes most sense to me is to view 2.30 as a dual release; to
have a set of stable modules that make up the normal GNOME 2 desktop
release and a set of preview modules that can be added on to get a
beta of the GNOME 3 experience. (By beta I mean not a release candidate,
but rather a stabilized version that is suitable for widespread use
and testing but may undergo substantial changes before the final
release.)

Purpose:
 
 GNOME Shell is intended to replace gnome-panel and Metacity in the
 GNOME 3 desktop; it takes on roles such as switching to windows,
 launching applications, and displaying and letting the user interact
 with notification.

Target:

 In GNOME 3, GNOME Shell will be a core part of the GNOME desktop.

Dependencies:

 In addition to standard GNOME platform and desktop modules, GNOME Shell
 currently depends on:

  Clutter: gnome-shell-2.30 will depend on Clutter 1.2 which is
    planned to be finalized around January.

  GJS and SpiderMonkey: Currently gnome-shell is build using the
    GJS bindings to Javascript which work with the Mozilla SpiderMonkey
    Javascript engine. The comparison to seed/JavascriptCore has been
    discussed quite a bit in the past, I don't want to go into in
    detail here; basically the advantages for us are:

     - We have it working right now and don't have to spend time
       converting things over.

     - We get access to a range of nice, but not essential, extensions
       to Javascript that have been added by the Mozilla developers
       based on their needs developing a complex application with JS;
       these include:

       - Destructuring assignments: [x,y] = event.get_coords();
       - let variables with lexical scoping
       - Array.forEach()

    In one sense SpiderMonkey is not a problematic dependency;
    SpiderMonkey is distributed as part of xulrunner, and will be
    present on virtually any computer where GNOME is available.
    GJS is a very small library on top of SpiderMonkey and poses
    few issues in its own. It probably would be a preview desktop
    module in the same category as Mutter and gnome-shell.

    On the other hand: it is conceptually messy for GNOME to depend
    on two Javascript implementations and runtimes and it might be
    a PR problem in presenting GNOME as a project that knows where
    it is going :-)
 
    And SpiderMonkey has another issue; it is distributed only as
    part of xulrunner, and the xulrunner libraries have no binary
    compat guarantees between minor versions, so things linked against
    SpiderMonkey can need a recompile for Firefox security updates.

    My feeling right now is to leave figuring out the Javascript
    engine situation as something to do as time permits, perhaps it
    will get clearer on its own if let sit. But if this is seen
    as a major problem, then we can prioritize to make sure that it is
    done early on.

  Mutter: Mutter is a conversion of Metacity to be a Clutter-based
    window manager and compositing manager. In addition to being used
    in gnome-shell, it is is a core component of Moblin. It's
    maintained jointly by me and Tomas Frydrych.

    (I'm not going to do a separate module proposal for Mutter, read
    this as a proposal for both; I'm not aware of any issues with
    Mutter that aren't a subset of those discussed in this proposal.)

  ? Zeitgeist: I'm a little uncertain about this; we have patches
    around (that I've promised to review, but haven't yet :-() that
    integrate the 0.2  branch of Zeitgeist into gnome-shell in a very
    straightforward way without changing the UI - it's basically used
    as a replacement for .recently-used.xbel.

    This is a reasonable first step to integration, but in itself
    doesn't motivate adding an extra dependency; that needs to be
    motivated by a better understanding of what it will do for users and
    what the user interface will look like for GNOME 3.

    My initial understanding of the Zeitgeist engine was that it was
    a data collection engine to collect a rich view of how the user
    used their computer over time, which would then be used to build
    an OLPC style journal interface; but that understanding fuzzes
    at the edges when people are pressed about this, things like
    deducing related documents from temporal overlaps and tagging
    enter into the picture. This doesn't make me comfortable.

    There are also questions here of the relationship with Tracker. If
    Tracker really lives up to its promise, shouldn't timeline
    information simply be extra metadata added in the Tracker store;
    after all, a timeline really is just an indexed and extended
    view of the classic ctime/mtime/atime metadata?

    If querying the Tracker database for this is a) not sufficiently
    efficient b) too cumbersome to code c) requires expert training
    in RDF, then that, to me, would throw doubt on the whole Tracker
    enterprise.

    What would make us most comfortable would be a comprehensive
    picture of how Tracker, Zeitgeist, and Nautilus work together
    with the shell to allow finding your stuff. Now it is probably
    not completely realistic for me to hang await for this to show
    up in my inbox in finished form, so the first step (from my
    technical perspective) is to get a clear statement of what the
    Zeitgeist engine does, what new user interfaces are enabled by
    that operation, what it does *not* do, and how it relates to 
    Tracker.

    If the Zeitgeist people are interested in being in GNOME 2.30,
    perhaps they can provide a similar preview module proposal to this
    and answer that question there.

Resource usage:

 GNOME Shell is the gnome-shell module in GNOME Git, the gnome-shell
 product in bugzilla.gnome.org, gnome-shell-list gnome org, and
 #gnome-shell on irc.gnome.org. 
  
Adoption:

 Packages of GNOME Shell are available for most major operating systems
 and distributions that use GNOME as a desktop either as part of the
 latest versions or from 3rd party sources. Nobody is currently
 using it as the default GUI.

GNOME-ness:

 In addition to the use of GNOME resources as mentioned above; 
 GNOME Shell development is being done as close to possible to the
 GNOME community; it has been a major topic of discussion at last
 years and this years Boston GNOME Summit and at GCDS this summer;
 the GNOME art and design community have been extensively
 consulted (we could use more help!), it is translated by the
 GNOME translation teams, and so forth.

License:

 GPL