Metacity, Mutter, GNOME Shell, GNOME-2.28
- From: Owen Taylor <otaylor redhat com>
- To: desktop-devel-list gnome org, gnome-shell-list gnome org
- Cc: Tomas Frydrych <tf o-hand com>, Neil Roberts <neil linux intel com>, Robert Bragg <bob o-hand com>
- Subject: Metacity, Mutter, GNOME Shell, GNOME-2.28
- Date: Mon, 23 Mar 2009 16:41:23 -0400
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
gnome-shell is set up as a Mutter plugin that is largely written in
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
replace the gnome-shell UI with something else. An advantage here is that
over time, the core Window management logic could be gradually rewritten
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.
] [Thread Prev