August 4, 2009
This article was contributed by Koen Vervloesem
GNOME 3 is the GNOME project's ambitious effort to take its desktop into
the future. A key component of the desktop is the window manager, which
defines much of the overall feel of the system. Thomas Thurman, the maintainer of
Metacity—GNOME's current window manager—is looking
ahead to "Mutter" as the window manager for GNOME 3.
Metacity 2 will gradually be
phased out in favor of Mutter; in GNOME 2.28 it will be an
alternative window manager, while in GNOME 3, it will take over the reins from
Metacity.
The GNOME Shell, responsible for the
new user experience in GNOME 3, runs as a plugin for Mutter. Started as a
fork of Metacity, Mutter uses the Clutter toolkit. Clutter does its
rendering using
OpenGL or OpenGL ES, so using it in Mutter makes hardware
acceleration for the window manager possible. Meanwhile, Clutter has just announced its 1.0
release.
500 bugs to squash
With Mutter becoming the new kid in town for GNOME 3, Metacity 2 will not
be actively developed any more, except for bug fixes. This makes Mutter
essentially Metacity 3. Of course people who would like Metacity 2 to
continue because they don't like the Clutter backend may fork it, but it
remains to be seen if that would happen. On his blog, Thurman welcomes anybody
to do that and offers them "as much support in doing so as
possible", but he will switch to working on Mutter himself. Besides
all the work that has been done over the years on Metacity, Mutter has 12
contributors with at least three commits. The project is maintained by Owen
Taylor and Tomas Frydrych.
This fork, however, has one big problem: what to do with the more
than five hundred bugs open against Metacity? As Thurman describes
on his blog, "this is more than one maintainer can humanly
tackle." The simplest "solution" is to close them all, a mistake
that GNOME has made in the past with the switch from GNOME 1.4 to GNOME
2. Jamie Zawinski called this the cascade of attention-deficit
teenagers model.
Thurman proposes a better solution: work through all
the bug reports, then decide what to do with each bug. Enhancement
requests will not be fixed, unless Mutter or GNOME Shell could use
it. Bugs that can be reproduced in Mutter should be reassigned. Bugs that
are already fixed in Mutter, such as enhancement requests, should be marked
as already fixed. Thurman kindly asks his readers to help him with this
painstaking work, for which no volunteers seem to have stepped up yet.
New directions for a window manager
The development of GNOME 3 seems to be bringing new ideas from many
different directions. Thurman has been doing some investigation into switching to a
CSS-based format for Metacity themes; as Mutter is just the new
incarnation of Metacity, many of these considerations directly carry over
into Mutter:
I am convinced that the current theme format is far
too complicated (or, it could be said, far too powerful) for the job it
does. Designing window border themes is not a very complicated matter, but
the current format makes it complicated through requiring complicated
algebraic expressions for placement.
Thurman is proposing a switch to CSS, or at least the use of CSS as an
alternative format. He sees several advantages of this approach:
- The Metacity/Mutter developers will be able to use existing libraries
for layout rather than doing it all with custom code in the window
manager.
- Theme designers will be able to use their existing knowledge of CSS
rather than having to learn a complicated new format.
- CSS's box model is far more amenable to a simple drag-and-drop editor
program than Metacity's current expression-based system.
Thurman is also imagining a theme designer, with a simple mode that is
a wizard: it would ask the user a series of questions and would then
produce some CSS code. An advanced mode would let the user edit each CSS
rule individually, and reflect the changes on the screen. He is also
working on a wiki, which he'll announce soon, that allows users to enter
CSS and render it to an image of the window borders:
The idea here is that people who like to play with
theme design are not necessarily the same people who like to build
experimental software, so this lets them test it out using only a web
browser.
Owen Taylor explains another new direction: Mutter will get application-aware
window management. More specifically it will get knowledge about
tabs:
Dave Jordan is working on a GNOME Shell Google Summer
of Code project to let applications export information about their tabs to
Mutter via window properties. This will allow, for example, switching
directly to a specific web browser tab, rather than switching to the
window, then switching to the tab.
Another developer, Sam Hoffstaetter, is working on letting the user
group together arbitrary
windows as tabs, something that so-called tabbed window managers
offer. Each application would think it had multiple windows open, but the
user would see them as tabs. The reasoning, which your author is very
sympathetic to, is as follows:
Being part of
the window-manager, every application would make use of tabs without having
to re-invent them specifically for that application. It has always struck
me that tabs were something that belonged into the window manager, not in
browsers, terminals, editors, etc.
Some issues with Mutter
Interesting as the new directions may be, some people fear that Mutter
will not run on older hardware. For example, the Sugar developers didn't
choose Mutter, and went for Metacity instead, exactly because of this
fear. However, Taylor puts that in perspective:
Our target for Mutter is to provide a good GL-based
compositor. This does exclude machines, like the first generation XO, that
have no 3D hardware. Almost any desktop or standard laptop built within the
last 5 years has sufficiently good graphics.
Another fear that has been expressed is that Mutter will be too tightly
coupled with GNOME 3. As GNOME Shell is a Mutter plugin, it depends on it,
so users will not be able to use another window manager with GNOME
Shell. According to Taylor, this integration is not coincidental but by
design. For example, supporting Compiz instead of Mutter would require
a window management abstraction layer that "greatly increases the
amount of work".
However, this approach is problematic for some use cases, as Sam
Spilsbury, one of the Compiz developers, pointed
out a few months ago:
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.
Of course it will perfectly be possible to create a GNOME desktop using
another window manager, but then the user would miss out on the new desktop
experience of GNOME Shell. For example, users will not be able to
swap GNOME's window manager with a flexible window manager such as xmonad and still leave all GNOME functionality
intact.
Accessibility growing pains
The fact that GNOME Shell and Mutter use Clutter directly makes support
for accessibility features such as AT-SPI (Assistive Technologies Service
Provider) tricky, because Clutter has no accessibility support at the
moment. GTK applications, on the other hand, have ATK (Accessibility
Toolkit) which talks with the AT-SPI daemon. However, there's no
inherent reason that a switch to a Clutter-based composited user interface
should pose any problem for accessibility. The switch in toolkits will need
a certain amount of reimplementation. That said, Taylor maintains that some
accessibility features such as good magnification could become much easier
in Mutter.
An active project to provide accessibility interfaces for Clutter is
Cally (the name stems from Clutter + a11y), originally funded by Nokia that
uses Clutter in Maemo 5. The main developer, Alejandro Piñeiro
Iglesias, explains the work he has done:
Cally implements Gnome's ATK interfaces for the basic Clutter objects, but
if you are using a custom Clutter object with extra functionality in your
application, probably extra accessibility support would be required, like
HAIL was required to implement the extra accessibility support for Hildon
widgets.
Cally would be useful to implement accessibility support in Mutter and
GNOME Shell, but Iglesias says he should check the code first and see what
he needs to implement and how. He presented
Cally [PDF.GZ] at the recent Gran Canaria Desktop Summit.
A fresh start
According to Taylor, Mutter is not that exciting in isolation, but it is
meant to provide a platform for building exciting user interfaces like
Moblin and GNOME Shell: "I'm personally pretty interested in getting
applications and the compositor properly synchronized so the user sees
everything drawn as smoothly and cleanly as possible." Thurman is
excited about the opportunity to get a fresh start and rethink how to
interact with the user:
We have been working for ten
years in a mindset which is now, of course, ten years old. There's only so
far you can go in a purely evolutionary line of development. That said, I'm
very glad the existing Metacity codebase is being integrated into Mutter
and not thrown away.
The new directions of CSS-based themes and application-aware window
management finally make GNOME's window manager more than a dull but
necessary component. However, the developers have made some decisions under
the hood that will not be popular in some circles. There is no fallback
option for those that cannot or do not want to use compositing, and the
integration of GNOME Shell with Mutter shuts out alternative window
managers. But maybe this is the price that must be paid for innovation.
(
Log in to post comments)
