Hi! > 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. Actually I am bit in favor of this approach. Having the window manager and the shell separated has the advantage that they can be used independently. Think about things like Gnome Mobile or Netbooks - probably you want a composited wm here but you don't want GNOME Shell (but probably another shell that is based on a mutter-plugin). I also like that mutter would only keep that code that is based on clutter. The RENDER stuff is mostly taken care of by compiz and metacity is for non-composited Desktops. All three have their use-cases. That said, besides testing from time to time (which is restricted by the state of current open-source api drivers vs. bad performance on my intel-graphik netbook) I am not very involved in gnome-shell development. Regards, Johannes
Attachment:
signature.asc
Description: This is a digitally signed message part