This page describes a proposal for a new concept of desktop contexts (previously known as Activities, but this term was already used in too many places) in GnomeShell, and is intended to draft its implementation and allow discussion around it. GnomeShell is the primary place where this should be worked on, but other projects need to be part of this in order to make it possible to implement most useful features.

Desktop contexts are saved sets of applications available for launching in a single click along with individual applications and documents. If possible, saved desktop contexts should also include information about the documents opened in the applications last time the context was used. We can add that context should also restore applications' states using GnomeSession, and that the are intended to be extended in as many ways as possible by extern applications, like web browsers (history and bookmarks), file managers (e.g. GnomeZeitgeist) and time trackers (e.g. ProjectHamster).

In GnomeShell, desktop contexts are linked to Metacity workspaces so that you can associate one or more workspaces to a context, and only one. Thus, you can dispatch different parts of your work on a context over several workspaces. Switching to another workspace will switch the current desktop context, and you'll be able to separate recent documents/applications tracking, and other preferences so that you always can access very quickly the elements you need in a given context.

Internal implementation

The current experimental implementation works as described below. Though, the plans are that desktop contexts should be stored by GNOME Zeitgeist and obtained by the Shell from there using D-Bus, rather than being stored by it.

Internally, desktop contexts are handled by a GObject class named ShellDesktopContexts, defined in src/shell-desktop-contexts.c, and instantiated as the 'desktop_context' member of the ShellGlobal class. The ShellDesktopContexts class keeps track of workspace switching in a timeline, and emits events that other modules can connect to to be told when current context has changed. Ideally, external applications should be able to connect to signals using D-Bus. The current context can also be retrieved by providing a timestamp. This is necessary because fast workspace switching can lead to confusion if events are not processed quickly enough, so requesting the current context should always be linked to a given X event.

Desktop contexts are identified by an integer to which properties are associated. This allows to rename a context without losing its data, which can be useful when your work slowly changes its nature so that the context should be updated. Properties are quite basic for now, and only include name and associated workspaces; they are stored in GConf under /apps/gnome/shell/desktop_contexts. The actual work should be done in a modular way, so that applications usage is stored in a context basis by the ShellAppMonitor class, and so on for other features. Applications' state restoring is a complex case that may need to be done from within GnomeSession rather than from GnomeShell; as a general rule, many features would need to be implemented externally, and would only get basic information from GnomeShell over D-Bus.