Mikkel's Gnome 3 Vision

This document is a working draft and will be updated whenever I feel like it

In my blog post of June 12th 2008 I summarize a debate that has been held on Planet Gnome about the Decadence of Gnome 2.0 as well as the future of Gnome.

On this page I will try to summarize the problems and concerns raised and outline a strategy of how to address them in a Gnome 3.0 project.

Identified Problems

The below bullet point list is ordered by relevance. What I find most relevant is at the top. It is important to empathize that all I consider all items on the list important, the bottom ones are just less important.

• P1 Writing "Yet Another Desktop" will not revolutionize anything. People have desktops already and we can only hope to make slight improvements here. We shouldn't expect to make ground shaking progress
  

  P2 Difficult to introduce radical new features without breaking stuff. This is partially because it is tricky to provide API and ABI stable libraries
  

  P3 Difficult to introduce radical new features without upsetting a lot of people
  

  P4 Incoherent feeling to the Gnome 2.0 software stack
  

  P5 Difficulties integrating with the operating system
  

  P6 It is not clear what audience we are aiming for with the Gnome 2.0 desktop
  

  P7 Some people want to radically change our interaction model and add animated effects, other people just want a simple, beautiful, working desktop
  

  P8 It is quite hard to set up a development environment working on Gnome trunk
  

What We Did Right

• R1 Having and API and ABI stable core have made it a lot easier for distros to ship Gnome

  R2 A consistent user interface that does not change radically over time

  R3 Iterative code improvements

History to Keep in Mind

• H1 Some whole hearted attempts at breaking new ground have apparently failed (Online Desktop, Pyro, Gimmie)
  

  H2 Windows Vista uptake has not been like a landslide to say the least, despite MS investing a lot of development effort on it, and it does in fact shipt loads of new fancy things that are not found in XP
  

  H3 KDE 4. I am not sure what we can learn from it. I think that their development model payed off, but others disagree. Before embarking on any big journey I think we should have a thorough look at the KDE 4 history.
  

The Plan

Here follows an outline of a plan on how to address the identified problems.

The Very Quick Version

Realizing this is going to be a long and dull document I present a summary of the whole content for the lazy persons among us.

• Don't focus on a particular technology or feature
• Do focus on cleanup up the framework. This cleanup involves
  • Making sure we are extensible everywhere
  • Key extension points should be based on a specification and a reference implementation
• Set the roadmap in stone early and work towards 3.0 inside the 2.* series. When we only have the incompatible steps left make the jump to 3.0
  • We are not in a rush. We can take this slowly to make the incompatible transition to 3.0 as painless as possible

Not Desktop, Workspace

In order to make it clear that I am not addressing a desktop-centric solution I am going to be using the term workspace to mean a generic graphical workspace on some electronic device - being, a laptop, phone, mini-laptop, kiosk, whatnot.

The Plan

Gnome Flavors

Most people probably think of Gnome as a desktop system. People in-the-know knows that there is also Gnome Mobile. As stated by many people on Planet Gnome it is about time we look past the desktop. There are lots of other places in need of more specialized workspaces. Also the target audience of Gnome as a desktop distribution is also not entirely clear.

Solution: Make official Gnome flavors. Currently we have two Desktop and Mobile. Others could include Legacy Desktop, Mini Desktop, Sandbox (with bleeding edge apps and lots of experimentation).

Core, Platform, and Flavor

I think we have a problem with our current Platform and Desktop split of our libraries. The core of the problem is that it is very hard to get into Platform which is the only place we make API and ABI guarantees. Because of this (and probably other reasons) Desktop has become more or less a heap of libraries for various purposes. Furthermore Platform contains some libs that we hardly ever use (or at least should not use), this may be because Platform was to widely scoped to begin with.

Solution: Scope module sets by functionality and stability. We have two base modules shared by all flavors Core and Platform. Each flavor has a private additional module without any interface guarantees. For example the Desktop flavor would consist of the Core, Platform, and Desktop modules. Here follows a short description of each module. I do purposely not define what exactly each module should contain, that is besides the point for now.

• Core: This module contains libraries that are pretty much going to be needed by all applications. This, in the sense that all libs in here are going to be needed. Gtk+ and GLib being obvious here. Configuration (if not part of GLib) should also go here.

  • Interface guarantees: API and ABI rock stable for the duration of the major release cycle (that would be 3.0)

  Platform: Any application is very likely require at least one library from this module. Examples could include web content rendering, terminal integration, emailing, PIM, password storage, database abstractions, etc.

  • Interface guarantees: API and ABI stable for with some explicit and strict rules for changing them. No matter what these rules are stability should still be a major goal. Examples of rules could be

    • Time based - fx 4 years, 6 months warning period at which point transition documentation must be ready
    • Only warning based, 1 year warning time where transition docs must be ready

  Flavor: Libraries for integration with application in the flavor, specialized libraries that can be shared, but are unlikely to be used more than two or three places.

  • Interface guarantees: None. But we do strive to keep them stable.

  Special - Bindings: This is a bonus package Bindings follow the rules of the category of the lib(s) they bind.

Making Stability Guarantees Easier

It is a hard task to put on one self to maintain an API and ABI stable library (see P2). In addition to the Core/Platform split mentioned above official guidelines for the libs should be published. These should contain information to maintainers on how to most easily maintain stability (for example outlined in Imendio's Gtk+-3.0 paper).

Portability of Core and Platform

Underlying technologies such as X11 or other should not be exposed in any public API in Core or Platform. While actual ports need not exist, we should keep them portable to other achitectures and OSes. This is needed because all flavors are going to use both Core and Platform.

Extensibility and Specifications

The most visible way to extend the "desktop as a whole" is through Nautilus plugins or panel applets. To be frank this is weak and inflexible. Several alternatives exist or are being worked on (fx GDesklets and Moonlight). We need to work out more generic ways to augment the user experience.

Solution: Specifications. At each point we want extensibility we write a specification. This spec should be language neutral and (in theory) implementable in any way a developer might desire. Examples of this could be:

• A dbus interface
• Dropping XML files in predefined dirs
• Probably others

The Gnome Platform module should contain libs to help implement these specs (not necessarily full implementations). This way Gnome flavors can easily replace either server or client side components as suiting to their needs.

New Features and Applications?

I imagine that we can get very close to 3.0 by working entirely within the 2.0 tree. Our focus should not be on developing any new specific features or applications, but building a framework where we can plug them in at any later point without breaking anything.

One (quite important) argument for adding a new bling feature or application would be to not let down users expectations. If we release 3.0 with a desktop that resembles the last 2.* 99.99% a lot of users would be disappointed. I would be perfectly happy though.

Now that I've said we don't need any new features let me add the "but" :-). There are two items that I feel our stack desperately needs (apart from a animation + scene graph framework in Gtk+ 3.0). Given that the Gnome community agrees on something close to my ideas here I am willing to work on both myself.

• GProxy A way to do dynamic method invocation. This can act as a dbus proxy too, as well as form as a base for an object relation mapper. I have a draft here

  GPlugin A generic way to do plugins, surprise! This has been brought up on d-d-l many times. I have some ideas that are correlated with my GProxy idea, the GPlugin draft is here.

Both these items are directly related to the extensibility stuff I have been banging on about.

The Gnome Shell

As mentioned earlier the only way to extend the general desktop is via panel applets, nautilus extensions, and in special cases tray icons. This is very limiting. What is worse is that tray icons are by far the easiest to develop, this has lead to a great many apps exposing tray icons when they really should provide applets. On top of the coding difficulty issue we also have

• Applications can not programmatically add an applet to the panel on runtime (atleast not in an obvious or easy way)
• FIXME insert other applet limitations

Solution: Enter the Gnome shell. The Gnome shell is a DBus service providing hooks to integrate into the workspace on many levels. The shell does not have a UI itself, but clients can expose themselves through it. In a Gnome Shell context the current panel would simply be a container in which clients (think: applets) can embed themselves. Another container could expose client UIs on the desktop.

FIXME: Finish spec for Gnome Shell and publish it and have a tool consume these.

OS Intergration

Expose interfaces for operating systems to implement PackageKit is the pioneer in this area. FIXME Elaborate on this

Execution

If it was not for a Gtk+ 3.0 requirement, all of which I have described could be done by extending our current code base, without breaking API and ABI. So let me make it crystal clear I don't believe in massive rewriting or huge API breaks, and I am sure the plan I've outlined will not cause it.

The Gnome Shell, GProxy, GPlugin can definitely be added in a Gnome 2.0 context (although having a panel applet vs Gnome shell split is a bit ugly, nothing is preventing it). We can write down exactly which libs will go away and which will go into Core, Platform, and Flavor modules. We already have this to some degree with the LibEgg and LibGnome* purging from our stack. When we have everything spec out formally and blessed by the higher powers, we can hack along on Gnome 2.* until we have aligned things to make a smooth transition to the new world order.

Plan Verification

FIXME: Explain how this takes into account all P, H, and Rs above.