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

[Sam Spilsbury <smspillaz gmail com>]

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.

Kind Regards,

Sam Spilsbury

>
> Using Compiz to create a GNOME desktop using GNOME applications, the
> GNOME control-center, and so forth will of course remain possible. We
> have no current plans to create hard dependencies on GNOME Shell within
> the GNOME desktop (just as there are no hard dependencies on gnome-panel
> now.)
>
> - Owen
>
>
>



-- 
Sam Spilsbury