Implementing the next GNOME shell

Owen Taylor

October 22, 2008

By now, I think most people have had a chance to look at the text and mockups that Vincent posted [ http://www.vuntz.net/journal/2008/10/22/494-desktop-shell-from-the-user-experience-hackfest-general-overview ] of the new desktop shell ideas that came out of the user experience hackfest. Obviously some parts of the ideas are controversial, some parts will be improved as we get some experience with them in practice, but it is a compelling set of ideas that I’m excited about trying out. So here I’d like to put out some ideas I have about how we could go about implementation. (Much of this was covered at a session we had Sunday morning at the GNOME summit where we presented the ideas that came out of the hackfest.)

One Process. The first thing to note is that the ideas don’t naturally split into “window manager” and “panel”. The “Activities” view combines showing the windows that are currently open with launchers for existing applications. It would be possible to add complex API’s to the window manager to allow putting extra things into its scene graph. But it is going to be far easier to simply work in a single process with clean internal programming interfaces.

Javascript. This is an area that really calls for a high level language. There’s going to be lots of code that needs experimentation to get the right user behavior, but not a lot of code that is implementing some complicated algorithm over lots of data. For applets (which would run within the shell), we want a low barrier to getting involved. Javascript doesn’t pull in another complicated platform, almost everyone is familiar with it to some extent another, it offers good possibilities for sandboxing applets, it’s pretty light-weight for memory, and there is a lot of work going on to make it fast. And, especially with some of the Mozilla JS-1.7/JS-1.8 improvements, it’s not as painful to work in as you are thinking.

Clutter. Once we mix together windows, other UI bits like panels, overlay views, and so forth, we need a scene graph to manage everything and put it on the screen. The obvious candidate is there is Clutter. Clutter isn’t (yet) a very good replacement for GTK+ for a general purpose application toolkit, but UI like what is mocked up in the designs very much plays to Clutter’s strengths. And its a big plus to me that Clutter has a tested, documented API… something we wouldn’t have for a custom written scene graph.

Start from Metacity. If the shell subsumes the window manager, then what we should avoid is spending a bunch of time getting all the window manager details right once again … how do you constrain sizes and positions? how do you read ICCCM properties? etc. For this reason, starting from an existing window manager codebase is the right thing to do. I’m less convinced that we should try to have a single code base that works both ways… being able to aggressively refactor, convert thing that would be better in a high level language to Javascript seems important.

So, those are my ideas. No running code, svn module, or even project name yet. But that should change soon. (Current leader for a project name is the exciting “gnome-shell”… gnomesh to go with gnomecc.)

11:11 am