Re: Finishing the mutter rename

[Owen Taylor <otaylor redhat com>]

On Fri, 2009-05-08 at 09:42 +0100, Tomas Frydrych wrote: 
> > 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.
> 
> I really do not want Mutter to have Metacity dependency; we need a
> solution that can work for distribution, not just for developers
> testing. Having a separate gnome-wm-data package is lot better solution
> -- can we not make it in a way that people need to either have the
> gnome-wm-data OR Metacity installed ?

OK, thinking this through in a lot of detail.

Scenarios:

 Distro ships GNOME-2.28 and gnome-shell/mutter along side Metacity

 Embedded distribution includes Mutter

 Developer jhbuilds gnome-shell on GNOME-2.26
 
 User installs packages of gnome-shell/mutter on a GNOME-2.26 system

Note: the jhbuild scenario is inherently a dire mess when it comes to
GConf. There is no way I'm aware of to install an application in a
non-system directory and have it pick up the right schemas and defaults.
(Without going to an entirely jhbuild session with a jhbuild GConfd.) My
only idea about how to fix this is to patch libgconf to support
client-side reading of schemas.

Approaches:

 Mutter duplicates the Metacity data, renaming them
   (Keys are /apps/metacity, themes are $theme/mutter-1)

   This does not work well if Metacity and Mutter are both installed
   for reasons described in my last mail: the GNOME preferences
   dialogs will get confused (Window, Appearance, and Keyboard
   Shortcuts) It also creates a maintenance problem for themes, since 
   we don't want to have two copies.

 Mutter depends on Metacity

   This works well for all the above scenarios, except that it is 
   ugly for an embedded distribution including Mutter and not Metacity.
   In that case, a package would have to be created that stripped down
   metacity into metacity-data.

 Data is moved from Metacity to gnome-wm-data, and not renamed.
   (Keys stay as /apps/metacity, themes are $theme/metacity-1)

   This works well for most of above scenarios - you can dual-install
   Metacity-2.28 and Mutter-2.28 both depending on gnome-wm; the
   embedded distro can ship gnome-wm. When you jhbuild, it's fine if the
   installed metacity schemas are picked up. A package of Mutter
   designed to be installed with GNOME-2.26 could use the schemas/themes
   installed by Metacity.

   The main disadvantages here are that we require changes to Metacity
   to accommodate it, and we get a confused dependency graph - Mutter
   depends on gnome-wm-data in some cases but not others.

 Data is moved from Metacity to gnome-wm-data, and renamed.
   (Keys changed to /apps/gnome-wm, themes are $theme/gnome-wm-1)

   Doing it this way avoids the confused dependency graph. It also is
   conceptually cleaner, since we don't have a non-metacity module
   calling stuff metacity.

   But, it requires a one-time key migration, and causes problems if
   installed along-side Metacity-2.26. (e.g., duplicated items in
   Keyboard Shortcuts)

I'm still think the Metacity dependency is simplest, and I don't think
the stripped down metacity package is to hard to create. But I'm not
opposed to the no-renaming version of gnome-wm-data either, if Thomas is
OK with it.

- Owen