Re: Module semi-proposal: gnome-shell

[Willie Walker <WillieWalker charter net>]

I also forgot to mention the issue with applets, which was raised in a
private e-mail to me.  As I understand it, the existing applets will all
need to be rewritten for GNOME Shell.  If this is the case, then we have
some issues where some accessibility applets (e.g., the MouseTweaks
dwell click applet and the {Sticky/Slow}Keys feedback keyboard applet)
would need to be ported.

Will

On Mon, 2009-11-02 at 20:15 -0500, Willie Walker wrote:
> 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