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

[Tomas Frydrych <tf linux intel com>]

Hi everyone,

Sam Spilsbury wrote:
>> I don't get why that statement is true. For a GNOME Shell project to
>> be successful, it hast to be freakin good.
>> Mac OS X and Windows XP are way far more successful desktop
>> environments than GNOME or KDE are, and they don't even have the
>> notion of swappable windows managers, and if they do, none uses them.
>>
>> So what's your point here?
> 
> See KDE. They've abstracted a lot of their stuff and made special
> efforts so that it works with other composite window managers.

There is one thing to be said for pretty much any abstraction -- it
gives you the worst of all possible worlds, makes most things possible,
and allows nothing to be done well. Abstractions are only meaningful if
you need to use multiple components of similar functionality
*concurrently*, in all other cases abstractions are just waste of effort
and HW resources. I dare to say that WMs fall into the latter category.

The argument for swappable window managers is not far removed for an
argument for swappable libc. The reality is users do not give the
proverbial about window managers, all they care about is a good, smooth,
pain free user experience, a system that allows them to do things *they*
care about with minimal effort and intrusion. There is only one thing
that really matters about a window manager -- the user should not know
they have one; as soon as the user is conscious of what a WM does and
does not do, and what WM they are using, it means we, the developers,
are getting in the way of what the users is actually doing.

Someone else in this thread mentioned that while swappable WMs are not
an issue, being able to degrade to a non-compositing WM is. Degrading is
not the right term for this; we want alternate desktop that can be run
on older (or crippled) HW. We already have that, so this really is a
non-issue; it does not matter that the legacy desktop is (very)
different from the new desktop, but it is important that legacy support
does not hold back future development.

The Gnome Shell should be all about enabling the user, everything else
is just a distraction. The way you achieve this is you pick one WM that
has the potential to enable you to achieve that goal with the least and
most sustainable effort and you get on with it. My guess is that the
Gnome Shell devs picked Mutter because it makes this easy, not least
because of its heritage of Metacity's reliable window management, but
also the fact it is build on common Gnome technologies (GObject,
Clutter), and because it is being developed precisely with view toward
what the Shell is about.

> From what I can see with the code, I know so far that gnome-shell is
> really just a plugin to gnome, making the job of abstracting it about
> 100 times easier. I don't think there needs to be a specific
> dependency on Mutter's scene graph - the shell isn't really
> transformed in any way, so it can just use the GL context and spawn
> another clutter context in which it draws on top.

Even if that was the case (which it is not), why would you want to do
that ? What exactly would you gain in the pursuit of the ultimate goal
of enabling the users  to focus on their tasks ? At best you gain just a
layer of indirection, wasting the users HW resources and impacting
performance. If it can be demonstrated that Compiz is technically a
superior starting point on which to build the Shell, that it will be
easier to develop the Shell on the top of it, that it has better
prospects for long-term maintainability, and that will provide useful
features improving the user experience that Mutter cannot facilitate,
then the Shell should be switched over to Compiz -- one or the other,
but both make no sense.

Kind regards,

Tomas