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

[Owen Taylor <otaylor redhat com>]

On Wed, 2009-03-25 at 20:54 +0900, Sam Spilsbury wrote:
> On Wed, Mar 25, 2009 at 12:47 AM, Owen Taylor <otaylor redhat com> wrote:
> > On Tue, 2009-03-24 at 16:17 +0900, Sam Spilsbury wrote:
> >> On Tue, Mar 24, 2009 at 8:18 AM, Johannes Schmid <jhs jsschmid de> wrote:
> >> > 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).
> >>
> >> Definitely. If the WM and the shell were integrated, it would mean
> >> that a severe chunk of functionality would be lost when using other
> >> window managers like compiz with GNOME. It's totally possible to
> >> separate the shell and the WM and instead abstract calls to the WM
> >> with DBUS. That way compiz can have a plugin to support functionality
> >> required by gnome-shell.
> >
> > To try and make GNOME Shell integrate with multiple window managers
> > would either greatly constrain the user interface vision or greatly
> > increase the amount of work involved. The power of the GNOME shell
> > approach is that we are working within the desktop scene graph of the
> > window manager/compositor.
> 
> Hi,
> 
> I'm not going to deal with a later remark about compiz, because I
> don't feel that this is what this discussion is about (Even though I
> am a compiz developer).
> 
> We at compiz actually had a discussion over the phone with all the
> developers, including those at Novell about the future direction of
> our project and what our place would be (especially with the recent
> KWin and GNOME-Shell projects). It would be difficult to have any sort
> of position within the desktop if those two projects were to take
> hold, however it would be very disappointing to see a lot of code be
> dropped, especially considering that it may not see a life in KWin or
> Mutter/Metacity-Clutter/GNOME-Shell.
> 
> We decided that KWin was not going to be a huge issue for us - it is
> perfectly up to the user to decide which WM they want to use, and if
> they used either, we believe there would be no significant loss in
> functionality.
> 
> GNOME-Shell on the other hand is a far greater issue for us. While I
> believe the panel will be kept around until 3.2, after that point, if
> users were to use compiz with GNOME, they would lose a significant
> chunk of essential functionality.
> 
> This is the dilemma I am sure a lot of other desktop-agnostic window
> managers are facing as well. It would essentially mean that users
> _must_ use your window manager in order to use their desktop as
> normal.
> 
> A lot of window managers are starting to tinker with compositing, and
> the functionality as far as I can see is easily achievable with any
> window manager. If GNOME-Shell were made into a library, then it would
> be possible for normal compositing window managers such as Mutter and
> Compiz to hook into events generated by that library and do all the
> effects themselves. This is certainly a much better approach than what
> we had originally planned - which was duplicate code from GNOME-Shell
> into a compiz plugin so that users don't lose functionality.
> 
> I understand that GNOME-Compiz relations have been rather sour
> recently (and it has been, up until last year, a dilemma we face with
> KDE), however working together on this one would be a great step
> forward between a productive relationship between the two projects.

GNOME Shell is an integrated window manager, compositor, and application
launcher. This integration isn't some coincidental thing,it is basic
requirement of the user interface thing

GNOME Shell depends on two things:

 - Metacity's basic window management code:  property fetching,
   stacking, etc, etc.
 - The Clutter OpenGL scene graph

Now, of course Compiz has window management code. And it knows how to
draw a scene with OpenGL. So we could have written GNOME Shell on top of
Compiz, but for various reasons we didn't.

Create some sort of "window management abstraction layer" and "scene
graph abstraction layer" is what I mean by "greatly increase the amount
of work". And by "greatly", I don't mean 20%, I mean multiple times the
work. Because any time we wanted to do anything that involved the parts
beneath the abstraction layer, we'd have to get the Compiz and Metacity
and Clutter developers to all agree.

And there would be no point. If working on top of Compiz was the right
way to go, then we should have done that. Doing it both ways would have
no benefit for all that pain. The code that's running beneath the user
interface makes no difference to the user.

And it's not like that in this hypothetical world you get GNOME Shell
plus all the Compiz stuff that you normally have. GNOME Shell
*conflicts* with the standard Compiz plugins. The scale plugin makes no
sense when GNOME Shell already does that in the overlay. Putting your
workspaces on a cube makes no sense when the overlay shows them in a
grid, and so forth.

So, basically, no I don't see a way that GNOME Shell coexists with
Compiz other than as two separate shells for the GNOME desktop.

- Owen