Finishing the mutter rename

[Owen Taylor <otaylor redhat com>]

So, we know have not one but *two* patches to rename files in Mutter to
make it parallel installable with Metacity:

 http://bugzilla.gnome.org/show_bug.cgi?id=581238

(Jon Nettleton and Vincent Untz independently did patches)

I spent some time looking at the two patches and wanted to write up some
of the issues that came up for discussion:

GConf Keys
==========
Both patches duplicate the entire set of Metacity keys to /apps/mutter.
This raises some issues:

 - Preferences won't be preserved on a Metacity => Mutter upgrade or
   when switching back and forth. (Something we expect people to do in
   the GNOME-2.28 timescale, though not for GNOME-2.30)

 - What does the "Windows" control center capplet set?

 - Installing both metacity-key.xml.in and mutter-key.xml.in will, 
   if I'm not mistaken, make the "Keyboard Shortcuts" dialog very
   confusing.

One complicating factor is the way the games that are played with the
keybinding schemas - there is a header file that is used to generate the
schemas, and also included into the source files.

Themes
======
Jon's patch preserves the complete set of themes, and the docs and DTD
for the themes and installs them as "Mutter" themes. Vincent's patch
removes the themes from Mutter.

What the best approach here may depend on what we do with window
management themes in Mutter in the long term

 - Do we preserve 100% compatability with the Metacity theme format
 - Do we gradually evolve the Metacity theme format
 - Do we preserve 100% compatability with the Metacity theme format
   for a while and then when we need something new and spiffy, dump
   it and start from scratch,.

(The third of these seems most attractive to me)

Options
=======
I think that duplicating the GConf keys isn't going to work out that
well. I'm very hesitant to create a duplicate copy of all the Metacity
themes.

So, I see two basic options for alternate ways of proceeding: first, we
could simply piggy-back off of Metacity, and depend on it installing
GConf schemas and themes.

The big advantage of this is that it requires no reorganization and
little work; we just remove the files from Mutter. We also don't have to
worry about the control-center dependency on libmetacity-private for
theme rendering - that just works out.

Disadvantages include the need to have Metacity installed to use Mutter;
this might be an issue on embedded devices (creation of a metacity-data
package at packaging time would be a possibility) and isn't attractive
long-term in the GNOME-3.0 timescale.

We would also have to figure out how to handle the use of
all-keybindings.h in the source code; we might have to duplicate the
keybinding data anyways to be able to build Mutter. Or would need to
require a new version of Metacity modified to install all-keybindings.h.

The other option would be to split data out of Metacity into say, a
gnome-wm-data that would have:

 - the GConf schemas (left as /apps/metacity)
 - all-keybindings.h
 - Themes
 - The theme parts of libmetacity-private (libgnome-wm-theme?)

That sounds conceptually appealing, but the gnome-wm-data wouldn't be
parallel installable with existing Metacity (because of schema
conflicts), which is a problem for people trying out Mutter. So, for
now, I think we should just require Metacity to be installed; it would
be very easy to switch to the gnome-wm-data approach later.

- Owen