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

[John Stowers <john stowers lists gmail com>]

On Mon, 2009-03-23 at 17:11 -0400, Owen Taylor wrote:
> On Mon, 2009-03-23 at 17:02 -0400, Colin Walters wrote:
> > On Mon, Mar 23, 2009 at 4:41 PM, Owen Taylor <otaylor redhat com> wrote:
> > >
> > > 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.
> > 
> > I'd like to toss in here:
> > 
> > 4)
> >  o Import "mutter" as a "branch" of metacity
> >  o When built, it installs its binary by default by default as
> > "metacity-compositor"
> >  o We share a common GConf schema subset (even if e.g. compositor has
> > a few more keys)
> >  o We share the bugzilla name "metacity"
> >  o Replay some of the non-compositing changes like GObject-ification
> > and introspection support on to mainline to reduce the divergence
> > 
> > There are some tradeoffs here, but I'd like to avoid creating a
> > distinct mutter "brand" and forking the GConf keys, even if the
> > display technology is changing a lot.
> 
> A branch in the (future) Metacity git repository is an interesting idea,
> in that it allows changes to be moved somewhat more conveniently between
> the trees.
> 
> 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.

I am sure there will be users that do not like the change in mental
model gnome-shell will bring. It would be a shame if those users missed
out on the improvements to Metacity (aka mutter).

I think whatever development model allows Metacity to ship with a
clutter based compositing backend, or an alternative metacity-clutter
binary would be best.

John

> How would you see packaging and installation working with your scheme?
> I don't see how different programs (metacity and metacity-clutter) could
> share the same GConf schema keys.
> 
> - Owen
> 
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list