Now that the GNOME-2.27 cycle is beginning, I'd like to come up with a definitive plan for how we are going to be developing the Metacity codebase in the context of Mutter and gnome-shell.
To review the current situation: - Metacity is developed in GNOME svn by Thomas Thurman and others. This version has some not-very-maintained RENDER compositing support, but is mostly the old classic WM we know and love. - Intel has a branch of metacity (called Mutter or metacity-clutter) that virtualizes compositing to support either RENDER (not maintained or tested) or GL and Clutter. This installs as 'metacity' and is cannot be parallel installed with normal metacity. - gnome-shell has its own private Mutter branch (on my personal server). Most changes we made have been merged into the Mutter branch and in some cases metacity, but there are some unmerged changes related, in particular, to custom keybindings and gobject-introspection support. gnome-shell is set up as a Mutter plugin that is largely written in Javascript and talks to Metacity and to libraries via gobject-introspection. The 'gnome-shell' executable is a Python wrapper script that runs metacity --mutter-plugins=gnome-shell. I have two strong goals for this development cycle; the first is that there is a centralized location for development of the Metacity+Clutter codebase, and that centralized location is in GNOME version control. The second is that when GNOME-2.28 is released users can install gnome-shell as part of their normal system and chose between it and normal Metacity. With that in mind, there are a couple of approaches that could be taken: 1) The Mutter and gnome-shell changes could be folded back into normal metacity; the goal of being able to run a normal uncomposited desktop for GNOME-2.28 would likely require keeping the dual composited and non-composited code-paths. These code paths exist currently in mutter, but aren't that well tested, are a bit of a pain to maintain and make some types of changes distinctly harder. There's a risk that we'd destabilize non-composited Metacity without providing any benefits. 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. 3) The source code could be imported into gnome-shell, the Mutter plugin system removed, and the use of Javascript hard-coded. Customization/extension would be done as Javascript extensions, which could conceivably entirely replace the gnome-shell UI with something else. An advantage here is that over time, the core Window management logic could be gradually rewritten in Javascript and the C core stripped down. Of these alternatives, while I have some fondness for the third approach, the second seems most immediately practical. There's a development philosophy that will help keep it closer to what we could achieve with the third approach, which is to see the plugin system as only a loader: once the plugin is loaded it talks directly to the Metacity core, which is extended as necessary. (Things have been moving in this direction already; it's become easier to hook into Metacity now that the core objects are largely GObject-ified allowing signals and properties.) If people agree with that (better ideas than any of the above also appreciated!) then we can move almost immediately. Nobody would be forced to switch from the current metacity-clutter repository, of course. Mechanical question of the transition would include: - Do we want to import Mutter as it exists now, and evolve from that, keeping all the version control history, or do we want to break it up, review it, remove dead ends (like the multiple compositor backends) and commit it as a fresh patch sequence. The second would be an enormous amount of work, and probably not worth it. - If we import Mutter as it exists now, do we import it literally, or do we convert Metacity using the git => svn import scripts, then rebase Mutter on top of that. I think the quality of the latter is considerably better and would recommend that. (And do we want historical maintenance branches of Metacity in the Mutter repository? I think not.) - What commit policies do we have for the Mutter module? I'm thinking that we go pretty wide open but with the requirement that every not-absolutely-trivial change needs one review. So, that's my thinking. Feedback appreciated. - Owen _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list