Re: Metacity, Mutter, GNOME Shell, GNOME-2.28

[Owen Taylor <otaylor redhat com>]

On Mon, 2009-03-23 at 17:23 -0400, Colin Walters wrote:
> On Mon, Mar 23, 2009 at 5:11 PM, Owen Taylor <otaylor redhat com> wrote:
> >
> > But it could also be confusing, and unless you are going to keep on
> > merging Metacity wholesale into mutter, there's not a big advantage in
> > having them in the same repository. 'git cherry-pick' has no special
> > intelligence over just applying a patch.
> 
> Right, it's mostly a branding thing.

In my mind, the brand is GNOME Shell. I don't think we need to brand the
bits of GNOME Shell that are written in C separately.
metacity-compositor is more descriptive, so probably better for an
"unbranded" component, but I'm not sure enough better to switch back
again.

> > How would you see packaging and installation working with your scheme?
> 
> OS vendors would need to ship separate "metacity-compositor" packages.
>  metacity-compositor would Depend: metacity.

Hmm, from the desktop vendor point of view, that's fine, especially for
GNOME-2.28, though I do see more pendantic distros splitting
metacity-schemas out of metacity. Not so good for the embedded case.

> > I don't see how different programs (metacity and metacity-clutter) could
> > share the same GConf schema keys.
> 
> What problems do you see?  Basically mutter would depend on the
> metacity schemas being installed from mainline.

The problem I was referring was that two different projects can't
install .schemas files with the same keys. If you didn't install the
metacity schemas again, that would help.

One conceivable problem is that it isn't clear to me that there's going
to be a nice split of:

 A) Shared keys for Metacity and Mutter
 B) Mutter-specific keys

After a while you might get to the point where it was pretty hard to
guess what key was where... historical keys would be in one place, more
recently added keys in another.

> Thinking about this a bit more, the end of this path is that the
> schemas, translations etc. are removed from the compositor branch, and
> it's really a separate project that depends on metacity installed.  It
> just has a fork of the core code and installs a distinct binary name

Splitting translations is going to be much more of a problem than 
schemas - how would you know if a string in mutter should be marked for
translation or not looking at the code base? You wouldn't. 

- Owen