Доброго времени суток. Из письма в форварде меня начинают посещать серьёзные сомнения в том, что GNOME 2.30 станет GNOME 3.0.
-- Alexey "Ktirf" Rusakov GNOME Project ALT Linux Team
--- Begin Message ---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, [email protected], 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 [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
--- End Message ---
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
_______________________________________________ Gnome mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/gnome
