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

[Sam Spilsbury <smspillaz gmail com>]

On Thu, Mar 26, 2009 at 1:07 AM, Owen Taylor <otaylor redhat com> wrote:
> 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:

I haven't had a chance to look at the code so far - so please correct
me if I am wrong.
>
>  - Metacity's basic window management code:  property fetching,
>   stacking, etc, etc.

Do you use standard X.org functions for this or do you communicate
directly with metacity? Ideally, unless the former functions are
broken, it would be nice to use them as they work with any window
manager.

>  - The Clutter OpenGL scene graph

I can say that one chunk of code compiz will need is something to
handle the scene graph model.

We have plans to implement a clutter backend, but that looks far into
the future - we could also have some code to convert between the
scene-graph and the vector*matrix system that we use currently.

I'm not the GL expert of compiz, and will have to ask Dennis about this though.

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

Not necessarily. We already with a number of kde and gtk/gnome's
abstraction layers. Whenever something changes in one of those, we
update our code. No questions asked.

If other window manager's do the same, that is their problem - people
don't have to use compiz/(insert-window-manager-here) but the fact
that it will actually allow them to use the functionality of their
desktop gives them an incentive to do so

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

I don't see this argument as valid. If people want to use the overlay
mode and compiz provides it - then compiz would provide it. If people
don't then they can use the scale and cube plugins. Otherwise, they
can turn them off or on as they please.

The main problem as I see it is that when users would want to use any
other (insert window manager here) then they would lose their panel,
and hence a crucial part of functionality in their desktop.

It's perfectly possible for compiz to reimplement the entire panel on
our own so that it is compatible with your applets, however that is
not a good way of going about it simply because of the amount of code
that needs to be written to do that.

We'd be perfectly happy to create a shared window manager/panel
interface for you - it's certainly a much nicer solution than the
former.

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

Kind Regards and hoping for co-operation,

Sam Spilsbury

-- 
Sam Spilsbury