Remove some obsolete documentation.
These date back to Evolution 1.x era or perhaps earlier.
This commit is contained in:
Matthew Barnes
@ -1,65 +0,0 @@
|
||||
CamelException
|
||||
CamelLock
|
||||
CamelLockClient
|
||||
CamelLockHelper
|
||||
CamelMovemail
|
||||
CamelOperation
|
||||
CamelProvider
|
||||
CamelUIDCache
|
||||
CamelURL
|
||||
CamelObject
|
||||
+ CamelAddress
|
||||
| + CamelInternetAddress
|
||||
| ` CamelNewsAddress
|
||||
+ CamelDataWrapper
|
||||
| + CamelMedium
|
||||
| | ` CamelMimePart
|
||||
| | ` CamelMimeMessage
|
||||
| ` CamelMultipart
|
||||
+ CamelCipherContext
|
||||
| ` CamelPgpContext
|
||||
+ CamelCMSContext
|
||||
| ` CamelSMimeContext
|
||||
+ CamelDiscoDiary
|
||||
+ CamelFolder
|
||||
| + CamelDiscoFolder
|
||||
| ` CamelVeeFolder
|
||||
| ` CamelVTrashFolder
|
||||
+ CamelFolderSearch
|
||||
+ CamelFolderSummary
|
||||
+ CamelMimeFilter
|
||||
| + CamelMimeFilterBasic
|
||||
| + CamelMimeFilterBestenc
|
||||
| + CamelMimeFilterCharset
|
||||
| + CamelMimeFilterCRLF
|
||||
| + CamelMimeFilterFrom
|
||||
| + CamelMimeFilterIndex
|
||||
| + CamelMimeFilterLinewrap
|
||||
| + CamelMimeFilterSave
|
||||
| ` CamelMimeFilterStripHeader
|
||||
+ CamelSasl
|
||||
| + CamelSaslAnonymous
|
||||
| + CamelSaslCramMD5
|
||||
| + CamelSaslDigestMD5
|
||||
| + CamelSaslKerberos
|
||||
| + CamelSaslLogin
|
||||
| ` CamelSaslPlain
|
||||
+ CamelService
|
||||
| + CamelStore
|
||||
| | + CamelRemoteStore
|
||||
| | | ` CamelDiscoStore
|
||||
| | ` CamelVeeStore
|
||||
| ` CamelTransport
|
||||
+ CamelSession
|
||||
` CamelStream
|
||||
+ CamelSeekableStream
|
||||
| + CamelSeekableSubstream
|
||||
| + CamelStreamFs
|
||||
| ` CamelStreamMem
|
||||
+ CamelStreamBuffer
|
||||
+ CamelStreamFilter
|
||||
+ CamelStreamNull
|
||||
` CamelTcpStream
|
||||
+ CamelTcpStreamOpenSSL
|
||||
+ CamelTcpStreamRaw
|
||||
` CamelTcpStreamSSL
|
||||
201
doc/Design
201
doc/Design
@ -1,201 +0,0 @@
|
||||
|
||||
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.
|
||||
|
||||
@ -1,13 +0,0 @@
|
||||
* Keybindings for the mailer
|
||||
|
||||
Delete key: Deletes message, moves forward.
|
||||
|
||||
* Keybindings for the composer
|
||||
|
||||
Control-s: Saves message to file.
|
||||
Control-w: Closes composer window.
|
||||
Control-Return: Sends message now.
|
||||
|
||||
F6: Opens find dialog.
|
||||
F7: Opens replace dialog.
|
||||
|
||||
@ -1,65 +0,0 @@
|
||||
|
||||
Here is how both the Evolution implementation and IDL namespacing
|
||||
is to be organized, NB. for implementations and oafinfo filenames we replace
|
||||
'/' with '_'
|
||||
|
||||
Files:
|
||||
|
||||
/GNOME/Evolution/
|
||||
|
||||
Addressbook/
|
||||
Calendar/
|
||||
Control
|
||||
gnomecal
|
||||
Composer/
|
||||
Mail/
|
||||
Notes/
|
||||
Shell/
|
||||
Summary/
|
||||
test
|
||||
rdf
|
||||
Wombat/
|
||||
|
||||
Components:
|
||||
|
||||
Shell components end in _ShellComponent, controls in _Control,
|
||||
executive summary components in _ExecutiveSummaryComponent and
|
||||
factories append 'Factory'.
|
||||
|
||||
GNOME/
|
||||
Evolution/
|
||||
|
||||
Shell
|
||||
|
||||
Addressbook/
|
||||
MiniCard/
|
||||
Control, ControlFactory
|
||||
SelectNames, SelectNamesFactory
|
||||
Control, ControlFactory
|
||||
ShellComponent, ShellComponentFactory
|
||||
Calendar/
|
||||
iTip/
|
||||
Control, ControlFactory
|
||||
Control, ControlFactory
|
||||
ShellComponent, ShellComponentFactory
|
||||
ExecutiveSummaryComponent, ExecutiveSummaryComponentFactory
|
||||
Mail/
|
||||
Control, ControlFactory
|
||||
ShellComponent, ShellComponentFactory
|
||||
ExecutiveSummaryComponent, ExecutiveSummaryComponentFactory
|
||||
Composer, ComposerFactory
|
||||
Notes/
|
||||
control, controlFactory
|
||||
shellComponent, shellComponentFactory
|
||||
Summary/
|
||||
rdf/
|
||||
SummaryComponent, SummaryComponentFactory
|
||||
test/
|
||||
Component, ComponentFactory
|
||||
|
||||
ShellComponent, ShellComponentFactory
|
||||
|
||||
Wombat/
|
||||
ServerFactory
|
||||
CalendarFactory
|
||||
|
||||
Reference in New Issue
Block a user