Re: Module semi-proposal: gnome-shell

[Willie Walker <WillieWalker charter net>]

Hi Owen:

Many thanks for making this a formal proposal for comments.  I think we
all want to get behind GNOME Shell as a nice whiz-bang feature to make
people want to move to GNOME 3.  With the magnification support going
into GNOME Shell, the accessibility team is also building in a
dependency on the success of GNOME Shell.  So - we want to see it
succeed.

GNOME Shell is currently pretty much inaccessible, however, with the big
deal breakers being keyboard traversal (try to accomplish GNOME Shell
activities without a mouse) and AT-SPI support (try to examine and
interact with GNOME Shell components via accerciser).  Theming is also
another issue, but perhaps not as strong as the other two.

Since accessibility is a core value of GNOME, these things really need
to be addressed before GNOME Shell is fully blessed, IMO.

Thanks!

Will

On Mon, 2009-11-02 at 17:12 -0500, Owen Taylor wrote:
> 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
> 
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list