Red Hat developer Owen Taylor has been working on GNOME for over a decade. Best known for his work on GTK+ and Pango, he has also served on the project’s board of directors. Since last fall, he has been heading development on the GNOME Shell, a replacement for the current panel and window manager that is scheduled to be the cornerstone of GNOME 3.0 in 2010. Recently, he took the time to talk about the origins of GNOME Shell, its advantages, and where it might be heading.
According to Taylor, GNOME Shell “began on the banks of the Bosporus”–a reference to the 2008 GUADEC, which has held in Turkey. “We were sitting outside the venue at a cafe table, myself, the current panel maintainer and a couple of other GNOME developers. We were talking about what we wanted to do with GNOME panel, and where it was going. It’s a very old and very mature code base, and it sort of does what it does, but we need some new user interface ideas, so what we decided to do was have a hackfest around the user interface.”
Several months later, the week before the GNOME Summit in Boston last October, the hackfest happened. “We broke into different subgroups, and one of the subgroups was about window management and how you deal with applications, and those were the ideas that turned into the first version of GNOME Shell. I was actually in one of the other groups, but when we came back to talk about our ideas, I thought this was really interesting. At that time, I was thinking about what we wanted to do next for part of my work at Red Hat, and we decided that we wanted to take these ideas and run with them. I’ve been pushing them ever since.”
The Design Philosophy
Taylor declines to specify the exact features planned for GNOME Shell, not wanting to create false expectations or to limit himself prematurely. However, he explains that one starting point for GNOME Shell was a critique of the existing desktop.
“We thought the existing desktop is a little too freeform,” Taylor explains. “The GNOME panel is extraordinarily flexible and you can move things around anyway you want it–which sounds very good, but means that the panel doesn’t really have any idea of what the things on the panel are. If you change screen resolutions, it can get confused.”
Another guiding critique was to make navigation less ambiguous. “Right now, with GNOME, it can be confusing to find what you’re doing if you have to open an application. The first question is what desktop it is on, and, if you don’t have it open, you have to go to the menu to get it started. So we wanted to have one place to go to do everything.
Yet another design principle was that the desktop should be suitable for a variety of devices. “We didn’t want to design just for a mobile device, or just for a small laptop, or just for a couple of monitors, but to try to do something that could adapt,” Taylor says.
The Schedule
The announcement in April that GNOME Shell would be featured in part of GNOME 3 has made little different to the project, Taylor says. “We were always thinking of GNOME Shell as a GNOME 3 component.” Current plans are for a beta to be available as an option for GNOME 2.28, and to become a default for GNOME 2.30, although the panel will still be available, although “not really part of the official release.”
Taylor is philosophical about the possibility of missing this schedule, but he points out several reasons for thinking that GNOME Shell could be released in time. To start with, GNOME Shell is being written in Javascript, a well-known language with a relatively limited set of libraries, making it easier to learn than other possible choices. To this base, GNOME Shell adds the use of OpenGL-based Clutter for drawing windows, which he describes as “making animation very easy,” and GObject Introspection, which consists of descriptions of various languages, and makes it easy for contributors to write in the programming language of their choice.
Other aspects that should help to keep GNOME Shell on schedule include the reuse of existing code, such as Metacity’s, making the project “just integration” to a large degree. Many of the features, too, are modular, so if they are not ready on time, they can be easily added later.
Nor, for the first release, is the project encouraging other GNOME applications to be rewritten to integrate into the GNOME Shell. “To some extent, we want to discourage too much of that going on in the short term,” he says. “We don’t want to be in the situation where we’re rewriting the world, because that will impede our ability to get a usable 3.0 out in time.”
Avoiding a Backlash
Despite the effort to limit the scope, Taylor is aware that GNOME 3.0 will be enough of a change to invite comparison with the release of KDE 4.0–a comparison that raises the possibility of a user reaction against the changes.
However, Taylor suggests that a user backlash is unlikely. “One fundamental difference is that we’re trying to work on a very constrained part of GNOME, even though it consists of radically different technologies. We’re not touching a lot of GNOME. the preference panel and applications are going to stay pretty much unchanged, and one of the things we’re not retiring is the file manager.” Nor does Taylor have any immediate plans to remove desktop icons, which, he is aware, can provoke strong reactions pro and con.
“I don’t know a whole lot about the technology of KDE 4,” he says, but my impression is that they tried to change just about everything about the desktop, while we’re just going to work on one of the big impact parts of the desktop. There are some obvious similarities, but I think we’re basically doing a different kind of project–although there are some obvious similarities, too, like trying to do a large change on the user interface.”
Probably, Taylor adds, some people will dislike the changes just because they are different. “But sometimes, you just have to accept that some people won’t like it. What you have to do is make it exciting enough and cool enough that a lot of people will like it. The question is whether we can make the GNOME Shell something people want to use and think is better for them. We’ve taken some steps already, but there’s still a lot to do with that.”
Taylor is concerned that some people “will come in and see a few screen shots and react to those screen shots,” ignoring the fact that the GNOME Shell is under rapid development.
However, he hopes that users will get involved in feedback rather than leaping to make complaints. Besides hardware problems, he hopes that people will be willing to give “detailed explanations about how [GNOME Shell] fits into their work. Because I think it’s often less interesting to hear that you really don’t like some small feature, but, if people can actually go in and describe how they work and how they tried to use the GNOME Shell–that makes things very interesting, because it gives us a way to think about what would have to be done to GNOME Shell to make it better.”
