Evolution Shell and Components

The evolution shell both centralizes control of version and upgrade handling and manages display of user interface. It provides the top level window as well as menu items that are applicable across all components. Built in components for Evolution include mail, contacts, calendar, tasks.

When Evolution is run it creates a shell (e-shell.h and e-shell.c) which can control multiple shell windows (e-shell-window.h and e-shell-window.c). A shell is a bonobo object which implements the Evolution-Shell.idl CORBA interface. Being a bonobo object allows subsequent invocations of Evolution to in fact trigger additional shell windows of an existing evolution process, by calling the createNewWindow interface method. This also has the drawback of not allowing Evolution to run in two displays at once (Bonobo can activate based on display, but the Camel mail library is not architected to run in the same user space in two processes at once). The two other shell interface methods are handleURI, which allows an already running evolution to handle uris like mailto:, and setLineStatus, which allows setting the online/offline status from the command line.


Evolution components are discovered during shell start up by doing a bonobo query for objects that support the interface in Evolution-Shell.idl. The shell creates a component registry (e-component-registry.h and e-component-registry.c) that performs the component query the first time information is demanded and stores results. Both the shell and the shell windows then use this data. During start up, if migration is required (changes to data or settings) the shell calls the upgradeFromVersion method and each component can upgrade data accordingly.

The shell window UI is populated by component controls obtained via the createControls component interface method, and components implement this by providing three bonobo controls - a sidebar control, a main view control and a status bar control. There are five major menu options driven by the shell window:

The New menu items are constructed by reading the userCreatableItems attribute on each component and constructing menu items based on each creatable item returned. If the user activates a New menu item, the shell window matches the item to a component and calls requestCreateItem with a unique string name obtained for the userCreatableItems attribute, the component is then to take appropriate actions to make the new item.

For Send/Receive the shell window calls back to the shell which simply calls the sendAndReceive method on the component. The only builtin component that acts on this is the mail component which sends pending mail and downloads new mail.

The online/offline state is at the shell level and applies to all shell windows and components. If Work Offline/Online is selected the shell window calls back to shell to set the status to online or offline as appropriate.

There are two phases for the Quit menu implementation, one is to prepare for quit using the requestQuit method which allows components to prepare for quitting by, for instance, prompting the user to save any unsaved changes. The component can abort the quit process by return false from the requestQuit method. If any component returns false, the shell will not exit. If all components return true, the quit method will be called and the components should shutdown, they are not allowed to abort the process at this point.

Evolution Calendar

The Evolution calendar is implemented in 2 components, one for the calendar itself, and another one for tasks. Both of these implement the Evolution::Component CORBA interface, needed to communicate with the Shell.

Calendar views

The calendar component has 3 different types of view widgets, all of them being a subclass of the generic ECalendarView, which implements all common things.

Both EDayView and EWeekView are based on GnomeCanvas, and thus all the e*view-*item* files implement the different canvas items that are drawn in the view/canvas.

For storing the data coming from the calendar backends, views use ECalModel-based classes, which in turn is based on ETreeModel, from GAL. The model is implemented as an array of components, having a separated field in a specific column of the array, which allows access to individual fields' values. There are 2 implementations of the ECalModel interface:

Calendar and task editors

The calendar and task editors use the same architecture, which is supported by two base classes:

There are, on top of that, many classes based on those two generic ones. Description First of all, there is EventEditor and TaskEditor, which implement, on top of CompEditor, the editors for events and tasks, respectively. The CompEditor base class contains virtual methods that need to be implemented by the subclasses. These are the following:

On the other hand, CompEditorPage provides an interface for editor pages. This interface contains the following virtual methods, that need to be implemented by pages.

This interface is implemented by several classes, some for the event editor, some others for the task editor:

Alarm daemon

The alarm daemon is the responsible to fire the alarms set up by the user in the calendar/tasks managed by Evolution.

Its mode of operation is very simple. When starting (notify-main.c), it creates the alarm notification CORBA service (alarm-notify.c), which in turn looks at all the available calendar and tasks sources, and adds them to the alarm queue (alarm-queue.c). The alarm queue, for each client added, retrieves all pending alarms since the last notification (/apps/evolution/calendar/notify/last_notification_time GConf entry) until midnight of the current day. Each alarm is sent to the alarm scheduler, which notifies a specific callback when the trigger for the alarm has been reached. At that time, the alarm queue, depending on the kind of alarm, it would display it (alarm-notify-dialog.c), run a specified program, play a sound or send an email.

Alarms are setup by using the alarm scheduler (alarm.c), which allow the addition and removal of alarms. Once alarms are added, the alarm scheduler runs a timeout function which, in short intervals, looks for pending alarms

Apps/Evolution/Evolution_Architecture (last edited 2013-08-08 22:50:11 by WilliamJonMcCann)