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

[Tomas Frydrych <tf o-hand com>]

Hi,

Sorry for the delayed response, was away last week.

Owen Taylor wrote:
> 1) The Mutter and gnome-shell changes could be folded back into normal
> metacity; the goal of being able to run a normal uncomposited desktop
> for GNOME-2.28 would likely require keeping the dual composited and
> non-composited code-paths. These code paths exist currently in mutter, 
> but aren't that well tested, are a bit of a pain to maintain and make 
> some types  of changes distinctly harder. There's a risk that we'd 
> destabilize non-composited Metacity without providing any benefits.

This was the original plan for mutter; however, the changes in mutter
have been lot more pervasive than originally envisaged, and preserving
the plain Matacity codepaths does indeed complicate things.

> 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.

At present that would be my preferred approach; my main concern is that
 as the Mutter and Metacity codebases increasing diverge, we will need
to start maintaining the WM part of Mutter in its own right, but I think
the long-term advantages of a leaner codebase would outweigh that.

> 3) The source code could be imported into gnome-shell, the Mutter plugin
> system removed, and the use of Javascript hard-coded. Customization/extension
> would be done as Javascript extensions, which could conceivably entirely
> replace the gnome-shell UI with something else. An advantage here is that
> over time, the core Window management logic could be gradually rewritten
> in Javascript and the C core stripped down.

This is currently not viable for our needs at Intel; things might be
different couple of years down the line, once the Shell itself is more
established, etc.

> Mechanical question of the transition would include:
> 
>  - Do we want to import Mutter as it exists now, and evolve from
>    that, keeping all the version control history, or do we want to
>    break it up, review it, remove dead ends (like the multiple 
>    compositor backends) and commit it as a fresh patch sequence.
>    The second would be an enormous amount of work, and probably
>    not worth it.

Apart from the enormous effort required, I would be concerned about the
potential for large-scale breakages with the latter.

>  - If we import Mutter as it exists now, do we import it literally,
>    or do we convert Metacity using the git => svn import scripts,
>    then rebase Mutter on top of that. I think the quality of the
>    latter is considerably better and would recommend that. (And
>    do we want historical maintenance branches of Metacity in the
>    Mutter repository? I think not.)

Inclined to agree, the rebase would be cleaner; the branches can go, as
far as I am concerned. Not too thrilled about the prospect of moving
back to svn though :( .

Tomas