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-l...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list