From 6bf0dab0770162e5eab74dd07f6f15089ea6f92e Mon Sep 17 00:00:00 2001 From: nobody Date: Tue, 22 Aug 2000 12:05:30 +0000 Subject: This commit was manufactured by cvs2svn to create tag 'CONTROL_CENTER_1_3_1'. svn path=/tags/CONTROL_CENTER_1_3_1/; revision=4928 --- help/Design | 201 ------------------------------------------------------------ 1 file changed, 201 deletions(-) delete mode 100644 help/Design (limited to 'help/Design') diff --git a/help/Design b/help/Design deleted file mode 100644 index 7b7cf6f821..0000000000 --- a/help/Design +++ /dev/null @@ -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 trough 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 troughout 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. - -- cgit v1.2.3