1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
|
The Evolution Project specification
Miguel de Icaza.
* Introduction
Evolution is a project aiming at providing the free software
community with a professional, high-quality tool for managing
mail, appointments, tasks and other personal information
tools.
We want to make Evolution a system that addresses our needs
(the free software development community) and we believe that
by addressing our needs, we will provide a system that will
scale in the years to come for other users that are just
starting to use computers and the internet.
The main objectives of Evolution are to provide these powerful
features, and to make the user interface as pretty and
polished as possible.
Evolution is a GNOME application and a number of auxiliary
CORBA servers that act as the storage backends.
Evolution will copy the best user interface bits and the best
ideas and features found on contemporary groupware systems.
* Evolution internals.
Evolution can store its information locally (files for mail,
calendar and address book) or on a remote server (imap/pop,
cap, ldap).
Given the importance of syncing in this modern PDA world,
the Evolution GUI acts as a client to the data repository.
The data repository is a GUI-less CORBA server called Wombat.
Wombat provides a unified access system to the calendar and
addressbook data (doing mail is a bit hard, so we are leaving
this as a TODO item for now).
Wombat's CORBA interfaces are notifier-based. This means that
CORBA requests sent to Wombat do not return values
inmediately, but rather than for Wombat requests the user has
to provide a CORBA object that will be notified of what
happened.
Yes, that sounds hairy. It is actually pretty simple. It
basically means that you submit requests to Wombat, and a
callback is invoked in your code when the request has been
carried away.
This enables a Palm to sync to the repository without having
the GUI for Evolution running. It also means that volunteers
will be able to write text-based and web-based versions of
Evolution (not me though :-).
* Evolution as a platform
Evolution is more than a client for managing the above
information: Evolution is a platform for building groupware
applications that use the above components to get their work done.
To achieve this Evolution is designed to be scriptable, and it
exports its internals through CORBA/Bonobo. It is implemented
as a collection of Bonobo containers and Bonobo components.
There is a clean separation between the views (the user
interface) and the model (the view). The views that we are
writing are GNOME based, and they talk to the Wombat CORBA
server.
Wombat takes care of notifications to the various clients for
the data.
* The overall organization
A bar similar to outlook provides shortcuts for accessing the
various resources managed by Evolution: mail folders,
contacts, tasks, journal entries, notes, messages and other
user-defined destinations.
* User interface widgets
** The ETable package
This package provides a way of displaying and editing tables.
Tables are displayed based on a TableColumn definition that
defines the layout used for the display. Table Columns can be
nested, and the package does grouping of information displayed
according to the criteria defined there.
This is used in multiple places throughout evolution: it is
used for the Mail summary display, for the TODO display and
TODO new data entry and for the address book.
Nesting in the address book can be performed on various
fields. For example, a first level of nesting could be
"Company" and a second level would be "Country" the result is
a 2-level tree that can be collapsed expanded and contains the
information sorted/grouped by those two criteria.
The user interface for this will be copied from Outlook: the
possibility of adding and removing fields with drag and drop
as well as grouping using drag and drop.
* The Mail system
** The Mail sources
The mail system will support 4 sources of mail:
POP3 (transfer to a local file).
IMAP
Local mbox format in $MAIL.
Local mbox format that have other delivery points.
On top of that, it will be possible to browse existing mbox
archives (and possibly other formats in the future, like
Mailbox and Maildir).
** Storing the mail
Mail that gets incorporated into the system is stored in mbox
format, and summary files are provided for quick access to the
files. No modifications to the file on disk is performed (I
am not quite sure about this, perhaps we want to add the
status flags and some method for adding metadata to the mail).
Summary files are rebuilt on demand or rebuild if the mbox
file and the summary file have got out of sync.
A Metadata system that will enable us to attach information to
a message will have to be designed and implemented (enabling
users to add annotations to mails, and special keywords and
flags in a per-message fashion).
** Folders
Michael Zucchi is working on a system that will let users
easily define rules for splitting their incoming mail into
physical folders.
A further refinement to Folders are Virtual Folders. This
basically provides a powerful search and viewing facility for
mail. It works like this: when a mail is "incorporated" into
Evolution it is scanned and indexed.
Then users can enter queries into Evolution that will search
the entire database of messages.
** Virtual folders
Virtual folders will enable users to read/browse their mail in
new ways: by specifying search criterias, these folders will
contain messages that match the criteria given.
There is more information about this in the libcamel
directory.
We will index all headers from a message, and possible the
contents of messages and keep those on a separate file, to
enable users to query their mail database.
** Mail summary display
The summary will be displayed using the ETable package, to
enable users to add a number of sorting criteria and various
display methods for the summary view.
The Outlook methods for displaying will be present on the
system.
Message threading will be supported in Evolution.
** Message display engine
We are going to be using a combination of
libcamel/limime/libjamie to parse messages and render them
into an HTML buffer.
* The HTML engine
The GtkHTML engine will be used to display messages, and will
be extended to support a number of features that we require:
internal handling of characters will be based on Unicode
* The message composer
Regular features found in composers will be added: connecting
the composer to the address book, support for drag and drop
for including attachments, editing the message, archiving
drafts and archiving messages sent.
Ettore has been working on adding editing support to the
GtkHTML and he is working currently on a Bonobo component that
will provide a ready-to-use Bonobo control for embedding into
other applications.
|
