diff options
| author | nobody <nobody@localhost> | 2003-12-09 09:57:09 +0800 |
|---|---|---|
| committer | nobody <nobody@localhost> | 2003-12-09 09:57:09 +0800 |
| commit | 4bdc9e9a392152dbdbfb68063f62f879335c4030 (patch) | |
| tree | 75bb0caf9afd4b94842023406d6a7938c5d8b2b7 /doc/white-papers | |
| parent | 0031a7166cd0f3fc0cec0b60c468ca22a8c45b0b (diff) | |
| download | gsoc2013-evolution-GEDIT_2_5_91.tar.gz gsoc2013-evolution-GEDIT_2_5_91.tar.zst gsoc2013-evolution-GEDIT_2_5_91.zip | |
This commit was manufactured by cvs2svn to create tag 'GEDIT_2_5_91'.GEDIT_2_5_91
svn path=/tags/GEDIT_2_5_91/; revision=23725
Diffstat (limited to 'doc/white-papers')
| -rw-r--r-- | doc/white-papers/calendar/calendar.sgml | 209 | ||||
| -rw-r--r-- | doc/white-papers/mail/camel.sgml | 356 | ||||
| -rw-r--r-- | doc/white-papers/mail/ibex.sgml | 158 | ||||
| -rw-r--r-- | doc/white-papers/widgets/e-table.sgml | 279 |
4 files changed, 0 insertions, 1002 deletions
diff --git a/doc/white-papers/calendar/calendar.sgml b/doc/white-papers/calendar/calendar.sgml deleted file mode 100644 index 2cb3132e2b..0000000000 --- a/doc/white-papers/calendar/calendar.sgml +++ /dev/null @@ -1,209 +0,0 @@ -<!doctype article PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [ -<!entity Evolution "<application>Evolution</application>"> -<!entity CUA "<acronym>CUA</acronym>"> -<!entity PCS "<acronym>PCS</acronym>"> -<!entity Bonobo "<application>Bonobo</application>"> -<!entity CORBA "<acronym>CORBA</acronym>"> -<!entity GTK "<acronym>GTK+</acronym>"> -]> - -<article class="whitepaper" id="calendar"> - - <artheader> - <title>&Evolution; Calendaring Framework</title> - - <authorgroup> - <author> - <firstname>Federico</firstname> - <surname>Mena Quintero</surname> - <affiliation> - <address> - <email>federico@helixcode.com</email> - </address> - </affiliation> - </author> - </authorgroup> - - <copyright> - <year>2000</year> - <holder>Helix Code, Inc.</holder> - </copyright> - - <abstract> - <para> - The &Evolution; groupware suite provides a framework for - developing calendaring applications, as well as a graphical - calendar client and a personal calendar server. This white - paper describes the architecture of the &Evolution; - calendaring framework. - </para> - </abstract> - </artheader> - - <!-- Introduction --> - - <sect1 id="introduction"> - <title>Introduction</title> - - <para> - Calendaring is an important part of a groupware suite. A - calendaring framework will allow a user to keep a personal - calendar and have several applications use it. Such - applications could be a graphical calendar client that the user - employs to schedule appointments and keep track of his time, a - <productname>Palm Pilot</productname> synchronization client, or - a simple alarm or reminder utility. A comprehensive calendaring - framework will also allow multiple users to schedule - appointments between each other; for example, a project director - may want to schedule a weekly meeting with the rest of the - project members, or a person who owns a large house may want to - schedule a big party with his friends. The attendees will then - want to reply with messages such as, “I will - attend”, or “I will attend only if the proposed time - is changed”. - </para> - - <para> - The &Evolution; groupware suite provides a framework for - developing calendaring applications, as well as a graphical - calendar client or calendar user agent (&CUA;) and a personal - calendar server (&PCS;). - </para> - - <para> - The following sections explain the basic calendaring framework, - the functions of the calendar user agent and the personal - calendar server, and the relationship between the two. - </para> - </sect1> - - <!-- Personal Calendar Server --> - - <sect1 id="pcs"> - <title>Personal Calendar Server</title> - - <para> - The personal calendar server (&PCS;) provides centralized - management and storage of a user's personal calendar. Multiple - clients can connect to the &PCS; simultaneously to query and - modify the user's calendar in a synchronized fashion. The main - features of the &PCS; are as follows: - </para> - - <formalpara> - <title>Storage</title> - - <para> - The &PCS; is responsible for loading and saving calendars. - Centralizing the loading and saving functionality allows - multiple clients to use the same calendar at the same time - without having to worry about each other. - </para> - </formalpara> - - <formalpara> - <title>Basic Queries</title> - - <para> - The &PCS; provides functions to do basic queries on a - calendar, for example, a client can ask the server for a list - of all the appointments in the calendar, or for all the data - for a specific appointment. - </para> - </formalpara> - - <formalpara> - <title>Recurrence and Alarm Queries</title> - - <para> - Clients can ask the &PCS; for a list of the appointments that - occur within a specified time range; for example a graphical - client that has a per-week view could ask the &PCS; for all - the appointments that occur in a particular week. This - includes multiple occurrences of a single recurring event; for - example, the object for “a 1-hour meeting that occurs on - every Tuesday and Thursday” is represented inside the - &PCS; as a single event with a recurrence rule. Similarly, - clients can ask the &PCS; for a list of events that have - alarms that trigger within a specified time range. - </para> - </formalpara> - - <formalpara> - <title>Notification of Changes</title> - - <para> - This is the most important function of the &PCS;, as it allows - multiple calendar clients to maintain a unified view of the - calendar between the server and themselves. When a client - asks the &PCS; to modify or remove an event, the &PCS; - notifies all the clients that are connected to it about the - change. The policy is that “the server is always - right”; clients can act as dumb views onto the - calendar's data and they will be notified by the &PCS; when - something changes. - </para> - </formalpara> - </sect1> - - <!-- Calenar User Agent --> - - <sect1 id="cua"> - <title>Calendar User Agent</title> - - <para> - A calendar user agent (&CUA;) is a program that lets a user - manipulate a calendar. &Evolution; provides an attractive, - graphical calendar client that communicates with the &Evolution; - personal calendar server. - </para> - - <para> - The &Evolution; calendar client just provides a view onto the - data that is stored and managed by the personal calendar server. - The calendar client does not perform direct manipulations on a - calendar's data; instead it offloads those requests to the - calendar server, which takes care of making the appropriate - modifications in the calendar and then notifies all the clients - about the changes. - </para> - </sect1> - - <!-- Calendar Client Library --> - - <sect1 id="client-lib"> - <title>Calendar Client Library</title> - - <para> - Communication between the personal calendar server and calendar - clients is defined by a set of &Bonobo; &CORBA; interfaces. - Clients can be written by implementing the client-side - <classname>Listener</classname> interface, which defines the - notification callbacks that the PCS uses to inform clients about - changes to the calendar. - </para> - - <para> - As a convenience for >K; programmers, &Evolution; also - includes a library which provides a - <classname>CalClient</classname> class which can be used for - communication with the personal calendar server. Objects of - this class automatically contact the PCS when they are created. - <classname>CalClient</classname> provides functions to request - changes in the calendar, and it also emits signals when it gets - notification about changes from the PCS. This makes it easy and - convenient to write calendar clients for &Evolution; using - >K;. - </para> - - <para> - The implementation of the <classname>CalClient</classname> class - simply wraps the &Evolution; &CORBA; interfaces for calendaring - with a familiar-looking >K; object. Calls to the - <classname>Listener</classname> interface get translated to - signal emissions from the <classname>CalClient</classname>, thus - shielding programmers from the details of the &CORBA; - interfaces. - </para> - </sect1> -</article> diff --git a/doc/white-papers/mail/camel.sgml b/doc/white-papers/mail/camel.sgml deleted file mode 100644 index 5f5ea27a98..0000000000 --- a/doc/white-papers/mail/camel.sgml +++ /dev/null @@ -1,356 +0,0 @@ -<!doctype article PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [ -<!entity Evolution "<application>Evolution</application>"> -<!entity Camel "Camel"> -]> - -<article class="whitepaper" id="camel"> - - <artheader> - <title>The &Camel; Messaging Library</title> - - <authorgroup> - <author> - <firstname>Jeffrey</firstname> - <surname>Stedfast</surname> - <affiliation> - <address> - <email>fejj@helixcode.com</email> - </address> - </affiliation> - </author> - - <author> - <firstname>Michael</firstname> - <surname>Zucchi</surname> - <affiliation> - <address> - <email>notzed@helixcode.com</email> - </address> - </affiliation> - </author> - - <author> - <firstname>Dan</firstname> - <surname>Winship</surname> - <affiliation> - <address> - <email>danw@helixcode.com</email> - </address> - </affiliation> - </author> - - <author> - <firstname>Bertrand</firstname> - <surname>Guiheneuf</surname> - <affiliation> - <address> - <email>bertrand@helixcode.com</email> - </address> - </affiliation> - </author> - </authorgroup> - - <copyright> - <year>2000, 2001</year> - <holder>Ximian, Inc.</holder> - </copyright> - - </artheader> - - <sect1 id="introduction"> - <title>Introduction</title> - - <para> - &Camel; is a generic messaging library. It is being used as the - back end for the mail component of &Evolution;. The name - "&Camel;" is an acronym; it refers to the fact that the - library is capable of going several days without food or water. - It means : Camel's Acronym Makes Everyone Laugh. - </para> - - <para> - &Camel;'s initial design is heavily based on Sun's - <trademark>JavaMail</trademark> API. It uses the Gtk+ object - system, and many of its classes are direct analags of JavaMail - classes. Its design has also been influenced by the features of - IMAP, and the limitations of the standard UNIX mbox mail store, - which set some of the boundaries on its requirements and - extensibility. - </para> - - <para> - &Camel; sees all message repositories as stores containing - folders. These folders in turn contain the messages the client - actually accesses. The use of such a unified interface allows - the client applications to be very extensible. &Camel; includes - an external provider mechanism which allows applications to - dynamically load and use protocols which were not available when - the application was initially written. - </para> - - <para> - The abstract store/folder mechanism is a powerful and versatile - way of accessing messages. No particular asumptions are made on - the client side, thus allowing new ways of managing the - messages. For example, the messages stored in the folders don't - necessarily have to share some common physical location. The - folder can be a purely virtual folder, containing only - references to the actual messages. This is used by the "vFolder" - provider, which allows you select messages meeting particular - criteria and deal with them as a group. - </para> - - <para> - In addition to these possibilities, &Camel; has full MIME - support. &Camel; MIME messages are lightweight objects - representing the MIME skeleton of the actual message. The data - contained in the subparts are never stored in memory except when - they are actually needed. The application, when accessing the - various MIME objects contained in the message (text parts, - attachments, embedded binary objects ...) asks &Camel; for a - stream that it can read data from. This scheme is particularly - useful with the IMAP provider. IMAP has strong MIME support - built-in, which allows &Camel; to download only the parts of - messages that it actually needs: attachments need not be - downloaded until they are viewed, and unnecessary - "multipart/alternative" parts will never be read off the server. - </para> - </sect1> - - <sect1 id="overview"> - <title>Overview</title> - - <graphic format="gif" fileref="camel"></graphic> - - <para> - To begin using &Camel;, an application first creates subclassed - <classname>CamelSession</classname> object. This object is used - to store application defaults, and to coordinate communication - between providers and the application. - </para> - - <para> - A <classname>CamelProvider</classname> is a dynamically-loadable - module that provides functionality associated with a specific - service. Examples of providers are POP, IMAP and SMTP. Providers - include subclasses of the various other &Camel; classes for - accessing and manipulating messages. - </para> - - <para> - <classname>CamelService</classname> is an abstract class for - describing a connection to a local or remote service. It - currently has two subclasses: <classname>CamelStore</classname>, - for services that store messages (such as IMAP servers and mbox - files), and <classname>CamelTransport</classname>, for services - that deliver messages (such as SMTP or a local MTA). A provider - could also be both a store and a transport, as in the case of - NNTP. - </para> - - <para> - A <classname>CamelStore</classname> contains some number of - <classname>CamelFolder</classname> objects, which in turn - contain messages. A <classname>CamelFolder</classname> provides - a <classname>CamelFolderSummary</classname> object, which - includes details about the subject, date, and sender of each - message in the folder. The folder also includes the messages - themselves, as subclasses of <classname>CamelMedium</classname>. - </para> - - <para> - Email messages are represented by the - <classname>CamelMimeMessage</classname> class, a subclass of - <classname>CamelMedium</classname>. This class includes - operations for accessing RFC822 and MIME headers, accessing - subparts of MIME messages, encoding and decoding Base64 and - Quoted-Printable, etc. - </para> - - <para> - <classname>CamelTransport</classname> includes methods for - delivering messages. While the abstract - <function>CamelTransport::send</function> method takes a - <classname>CamelMedium</classname>, its subclasses may only be - able to deliver messages of specific - <classname>CamelMedium</classname> subclasses. For instance, - <classname>CamelSendmailTransport</classname> requires a - <classname>CamelMimeMessage</classname>, because it needs a - message that includes a "To:" header. A hypothetical - <classname>CamelNNTPTransport</classname> would need a - <classname>CamelNewsMessage</classname>, which would have a - "Newsgroups:" header. - </para> - - <para> - The content of messages are referred to using - <classname>CamelStream</classname> and its subclasses. In the - case of an mbox-based store, the - <classname>CamelStream</classname> would abstract the operation - of reading the correct section of the mbox file. For IMAP, - reading off the <classname>CamelStream</classname> might result - in commands being issued to the remote IMAP server and data - being read off a socket. - </para> - - <para> - The final major class in &Camel; is - <classname>CamelException</classname>, which is used to - propagate information about errors. Many methods take a - <classname>CamelException</classname> as an argument, which the - caller can then check if an error occurs. It includes both a - numeric error code which can be interpreted by the program, and - a text error message that can be displayed to the user. - </para> - </sect1> - - <sect1 id="classes"> - <title>Major Subcomponents</title> - - <sect2 id="store"> - <title>The Message Store</title> - - <para> - A <classname>CamelStore</classname> inherits the ability to - connect and authenticate to a service from its parent class, - <classname>CamelService</classname>. It then adds the ability - to retrieve folders. A store must contain at least one folder, - which can be retrieved with - <function>CamelStore::get_default_folder</function>. There are - also methods to retrieve the "top-level" folder (for - hieararchical stores), and to retrieve an arbitrary folder by - name. - </para> - - <para> - All <classname>CamelFolder</classname>s must implement certain - core operations, most notably generating a summary and - retrieving and deleting messages. A - <classname>CamelFolder</classname> must assign a permanently - unique identifier to each message it contains. Messages can - then be retrieved via - <function>CamelFolder::get_message</function>. - </para> - - <para> - Folders must also implement the - <function>get_parent_folder</function> and - <function>list_subfolders</function> methods. For stores that - don't allow multiple folders, they would return NULL and an - empty list, respectively. Stores that do allow multiple - folders will also define methods for creating and deleting - folders, and for moving messages between them (assuming the - folders are writable). - </para> - - <para> - Folders that support searching can define the - <function>search_by_expression</function> method. For mbox - folders, this is implemented by indexing the messages with the - ibex library and using that to search them later. For IMAP - folders, this uses the IMAP SEARCH command. Other folder types - might not be able to implement this functionality, in which - case users would not be able to do full-content searches on - them. - </para> - </sect2> - - <sect2 id="messages"> - <title>Messages</title> - - <para> - As mentioned before, messages are represented by subclasses of - <classname>CamelMedium</classname>. - <classname>CamelMedium</classname> itself is a subclass of - <classname>CamelDataWrapper</classname>, a generic class for - connecting a typed data source to a data sink. - <classname>CamelMedium</classname> adds the concept of message - headers versus message body. - (<classname>CamelDataWrapper</classname> has one other - important subclass, <classname>CamelMultipart</classname>, - which is used to provide separate access to the multiple - independent parts of a multipart MIME type.) - <classname>CamelMedium</classname>'s subclasses provide more - specialized handling of various headers: - <classname>CamelMimePart</classname> adds special handling for - the &ldquot;Content-*&rdquot; headers in MIME messages, and - its subclass <classname>CamelMimeMessage</classname> adds - handling for the RFC822 headers. - </para> - - <graphic format="gif" fileref="mimemessage"></graphic> - - <para> - Consider a message with two parts: a text part (in both plain - text and HTML), and an attached image: - - <programlisting> - - From: Dan Winship <danw@helixcode.com> - To: Matt Loper <matt@helixcode.com> - Subject: the Camel white paper - MIME-Version: 1.0 - Content-Type: multipart/mixed; - boundary="jhTYrnsRrdhDFGa" - - This is a multi-part message in MIME format. - --jhTYrnsRrdhDFGa - Content-Type: multipart/alternative; - boundary="sFSenbAFDSgDfg" - - --sFSenbAFDSgDfg - Content-Type: text/plain - - Hey, Matt - - Check out this graphic... - - -- Dan - - --sFSenbAFDSgDfg - Content-Type: text/html - - Hey, Matt<br> - <br> - Check out this graphic...<br> - <br> - -- Dan<br> - <br> - --sFSenbAFDSgDfg-- - - --jhTYrnsRrdhDFGa - Content-Type: image/png - Content-Transfer-Encoding: base64 - - F4JLw0ORrkRa8AwAMQJLAaI3UDIGsco9RAaB92... - --jhTYrnsRrdhDFGa-- - </programlisting> - - <para> - In &Camel;, this would be represented as follows: - </para> - - <graphic fileref="samplemsg"></graphic> - </sect2> - - <sect2 id="streams"> - <title>Streams</title> - - <para> - Streams are a generic data transport layer. Two basic stream - classes are <classname>CamelStreamFs</classname>, for - reading and writing files, and - <classname>CamelStreamMem</classname>, for reading from and - writing to objects that are already in memory. - </para> - - <para> - Streams can also be filtered. So a CamelMimePart - containing base64-encoded data can filter its output through - CamelMimeFilterBasic. Other parts of the application that want - to read its data will never need to even realize that the - original data was encoded. - </para> - </sect2> - -</article> diff --git a/doc/white-papers/mail/ibex.sgml b/doc/white-papers/mail/ibex.sgml deleted file mode 100644 index dcb8f5ca4b..0000000000 --- a/doc/white-papers/mail/ibex.sgml +++ /dev/null @@ -1,158 +0,0 @@ -<!doctype article PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [ -<!entity Evolution "<application>Evolution</application>"> -<!entity Camel "Camel"> -<!entity Ibex "Ibex"> -]> - -<article class="whitepaper" id="ibex"> - - <artheader> - <title>Ibex: an Indexing System</title> - - <authorgroup> - <author> - <firstname>Dan</firstname> - <surname>Winship</surname> - <affiliation> - <address> - <email>danw@helixcode.com</email> - </address> - </affiliation> - </author> - </authorgroup> - - <copyright> - <year>2000</year> - <holder>Helix Code, Inc.</holder> - </copyright> - - </artheader> - - <sect1 id="introduction"> - <title>Introduction</title> - - <para> - &Ibex; is a library for text indexing. It is being used by - &Camel; to allow it to quickly search locally-stored messages, - either because the user is looking for a specific piece of text, - or because the application is contructing a vFolder or filtering - incoming mail. - </para> - </sect1> - - <sect1 id="goals"> - <title>Design Goals and Requirements for Ibex</title> - - <para> - The design of &Ibex; is based on a number of requirements. - - <itemizedlist> - <listitem> - <para> - First, obviously, it must be fast. In particular, searching - the index must be appreciably faster than searching through - the messages themselves, and constructing and maintaining - the index must not take a noticeable amount of time. - </para> - </listitem> - - <listitem> - <para> - The indexes must not take up too much space. Many users have - limited filesystem quotas on the systems where they read - their mail, and even users who read mail on private machines - have to worry about running out of space on their disks. The - indexes should be able to do their job without taking up so - much space that the user decides he would be better off - without them. - </para> - - <para> - Another aspect of this problem is that the system as a whole - must be clever about what it does and does not index: - accidentally indexing a "text" mail message containing - uuencoded, BinHexed, or PGP-encrypted data will drastically - affect the size of the index file. Either the caller or the - indexer itself has to avoid trying to index these sorts of - things. - </para> - </listitem> - - <listitem> - <para> - The indexing system must allow data to be added to the index - incrementally, so that new messages can be added to the - index (and deleted messages can be removed from it) without - having to re-scan all existing messages. - </para> - </listitem> - - <listitem> - <para> - It must allow the calling application to explain the - structure of the data however it wants to, rather than - requiring that the unit of indexing be individual files. - This way, &Camel; can index a single mbox-format file and - treat it as multiple messages. - </para> - </listitem> - - <listitem> - <para> - It must support non-ASCII text, given that many people send - and receive non-English email, and even people who only - speak English may receive email from people whose names - cannot be written in the US-ASCII character set. - </para> - </listitem> - </itemizedlist> - - <para> - While there are a number of existing indexing systems, none of - them met all (or even most) of our requirements. - </para> - </sect1> - - <sect1 id="implementation"> - <title>The Implementation</title> - - <para> - &Ibex; is still young, and many of the details of the current - implementation are not yet finalized. - </para> - - <para> - With the current index file format, 13 megabytes of Info files - can be indexed into a 371 kilobyte index file—a bit under - 3% of the original size. This is reasonable, but making it - smaller would be nice. (The file format includes some simple - compression, but <application>gzip</application> can compress an - index file to about half its size, so we can clearly do better.) - </para> - - <para> - The implementation has been profiled and optimized for speed to - some degree. But, it has so far only been run on a 500MHz - Pentium III system with very fast disks, so we have no solid - benchmarks. - </para> - - <para> - Further optimization (of both the file format and the in-memory - data structures) awaits seeing how the library is most easily - used by &Evolution;: if the indexes are likely to be kept in - memory for long periods of time, the in-memory data structures - need to be kept small, but the reading and writing operations - can be slow. On the other hand, if the indexes will only be - opened when they are needed, reading and writing must be fast, - and memory usage is less critical. - </para> - - <para> - Of course, to be useful for other applications that have - indexing needs, the library should provide several options, so - that each application can use the library in the way that is - most suited for its needs. - </para> - </sect1> -</article> diff --git a/doc/white-papers/widgets/e-table.sgml b/doc/white-papers/widgets/e-table.sgml deleted file mode 100644 index 5ff4faf2ae..0000000000 --- a/doc/white-papers/widgets/e-table.sgml +++ /dev/null @@ -1,279 +0,0 @@ -<!doctype article PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [ -<!entity Evolution "<application>Evolution</application>"> -<!entity ETable "<classname>ETable</classname>"> -<!entity ETableModel "<classname>ETableModel</classname>"> -<!entity ETableSimple "<classname>ETableSimple</classname>"> -<!entity ETableHeader "<classname>ETableHeader</classname>"> -<!entity ETableSpecification "<classname>ETableSpecification</classname>"> -<!entity ETableCol "<classname>ETableCol</classname>"> -]> - -<article class="whitepaper" id="e-table"> - - <artheader> - <title>The ETable Widget</title> - - <authorgroup> - <author> - <firstname>Chris</firstname> - <surname>Lahey</surname> - <affiliation> - <address> - <email>clahey@helixcode.com</email> - </address> - </affiliation> - </author> - <author> - <firstname>Miguel</firstname> - <surname>de Icaza</surname> - <affiliation> - <address> - <email>miguel@helixcode.com</email> - </address> - </affiliation> - </author> - </authorgroup> - - <copyright> - <year>2000</year> - <holder>Helix Code, Inc.</holder> - </copyright> - - </artheader> - - <sect1 id="introduction"> - <title>Introduction</title> - - <para> - &ETable; is a table widget on steroids. It is intended to provide - all the table functionality needed throughout &Evolution;, and - hopefully be general purpose enough to be used in other projects. - </para> - - <para> - &ETable; provides a lot of interactive control over the data in the - table. Without any work from the programmer, &ETable; provides - rearrangeable columns and editable data. When finished, &ETable; will - also provide, again with no programmer intervention, easy interactive - sorting and grouping. - </para> - - <para> - &ETable; gives you a great deal of functionality, flexibility, and - power. Most of this power is internal to the widget, but some of - the flexibility requires a bit of work by the programmer. - However, once you learn it, &ETable; is not very hard at all to - use. - </para> - - <para> - &ETable;'s power comes from the fact that it is fully - model/view/controller based. Various models are involved into - the process of rendering the information, and various views are - provided. The programmer has a wide range of options: from the - most finely hand-tuned table to a generic all-encompasing widget - that takes over most of tasks. It is up to the programmer: he - can use the simple to use &ETable; widget that takes care of - everything in a generic way, or he can use the various - components to roll his own tabular display. - </para> - - <para> - &ETable; ships with a standard set of information renderers: - strings, bitmaps, toggle-buttons, check-boxes, and multi-line - strings. But the programmer can write and implement his own - renderer for his information. This means that by default - &ETable; provides the basic display facilities that programmers - required, but they offer the programmer a complete freedom to - incorporate new cell renderers. - </para> - - </sect1> - - <sect1 id="model"> - <title>ETableModel</title> - - <para> - The data back end for the &ETable; is an &ETableModel;. The - &ETableModel is an abstract interface that acts as the - information repository for the various &ETable components. - </para> - - <para> - To use &ETable; you have to create a subclass of the abstract - &ETableModel; class. However, to save you the work of defining - a new <classname>GtkClass</classname> every time you use - &ETable, there is a predefined subclass of &ETableModel; called - &ETableSimple; which simply takes a list of function callbacks - to perform the various operations. - </para> - - </sect1> - - <sect1 id="columns"> - <title>Columns</title> - - <para> - There are two different meanings to the word "column". The first - is the model column (defined by the &ETableCol: object). A model - column describes how it maps to the column in the &ETableModel; - as well as containing information about its properties (name, - resizability, resize dimensions, and a renderer for this - specific columns). - </para> - - <para> - &ETable; distinguishes between a model column index, and a view - column index. The former reflects the column in which the data - is stored in the &ETableModel; The later represents the actual - location at which the column is being displayed in the screen. - </para> - - <para> - Each view column index corresponds to a specific model column, - though a model column may have any number of view columns - associated with it (including zero). For example the same - column might be rendered twice, or the data from one column - could be used to display different bits of information - </para> - - <para> - The view column does not necessarily depend on only one model - column. In some cases, the view column renderer can be given a - reference to another model column to get extra information about - its display. For example, a mail program could display deleted - messages with a line through them by creating a model column - with no corresponding view column that told whether or not the - message is deleted, and then having the text column - strikethrough the display if the invisible column had a value - corresponding to "deleted". - </para> - - <para> - The view column also specifies a few other pieces of - information. One piece of information is the renderer. &ETable; - provides a number of renderers to choose from, or you can write - your own. Currently, there are renderers for text, image sets, - and checkboxes. - </para> - - <para> - The view column also includes information about the header. - There are two types of headers: text, and pixbuf. The first - allows you to specify a string which is rendered in the header. - The second allows you to specify an image to copy into the - header. - </para> - </sect1> - - <sect1 id="header"> - <title>Header</title> - - <para> - The &ETableHeader; represents the header information for the - table. The &ETableHeader; is used in two different ways. The - first is the in the <structfield>full_header</structfield> - element of an &ETable;. This is the list of possible columns in - the view. You add each of your columns to this &ETableHeader; - and then pass it into the &ETable;. - </para> - - <para> - The second use is completely internal. &ETable; uses another - &ETableHeader; to store the actual displayed columns. Many of - the &ETableHeader; functions are for this purpose. The only - functions that users of the library should need to use are - <function>e_table_header_new</function> and - <function>e_table_header_add_col</function>. - </para> - </sect1> - - <sect1 id="layout"> - <title>Layout Specification</title> - - <para> - &ETable; uses an &ETableSpecification; to layout the columns of - the widget. The &ETableSpecification; is specified as XML data - passed into the &ETable; as a string. - </para> - - <para> - The most powerful part of the &ETableSpecification; is that when - finished, &ETable; will allow you to get a copy of an - &ETableSpecification; that describes the current view of the - tree. This allows the developer to save the current view so that - next time the user opens this table, they find it in exactly the - state that they left it. - </para> - - <para> - The XML specification allows for a number of things. First, it - allows you to pick a set of default columns to be shown. Thus, - even if you had hundreds of pieces of data, you could choose to - only display a few that fit on the screen by default. - </para> - - <para> - The second major thing that the &ETableSpecification; allows you - to specify is the column grouping and sorting. &ETable; has a - powerful mechanism for allowing the user to choose columns to - group by, thus allowing multiple columns of sorting, as well as - visual grouping of similar elements and interactive selection of - what data to display. - </para> - - <para> - The grouping in &ETableSpecification; is specified as a - hierarchy of columns to group by. Each level of the hierarchy - lets you sort by a particular column, either ascending or - descending. All levels except the last cause the canvas to group - by the given column. - </para> - - <para> - An example &ETableSpecification; follows. - </para> - - <programlisting> - <ETableSpecification> - <columns-shown frozen_columns="2"> - <column> 0 </column> - <column> 1 </column> - <column> 2 </column> - <column> 3 </column> - <column> 4 </column> - </columns-shown> - <grouping> - <group column="3" ascending="1"> - <group column="4" ascending="0"> - <leaf column="2" ascending="1"/> - </group> - </group> - </grouping> - </ETableSpecification> - </programlisting> - - <para> - This example has 5 columns which are initially in order. It has - 2 levels of grouping. The first is grouped by the 4th column - (all indexes are 0 based) and sorts those groups in ascending - order. Inside those groups, the data is grouped by the fifth - column and sorted in descending order of the fifth column. - Finally, the data in those groups is sorted by the third column - in ascending order. Due to the "frozen_columns" attribute on the - columns-shown element, the user will not be - able to rearrange the first two columns. They will always be the - first two. - </para> - </sect1> - - <sect1 id="conclusion"> - <title>Conclusion</title> - - <para> - All in all, &ETable; is a very powerful widget. Once you learn - to use it, you have access to a vast amount of power requiring a - comparatively small amount of work. - </para> - </sect1> -</article> |