diff options
Diffstat (limited to 'doc')
42 files changed, 0 insertions, 8097 deletions
diff --git a/doc/.cvsignore b/doc/.cvsignore deleted file mode 100644 index 282522db03..0000000000 --- a/doc/.cvsignore +++ /dev/null @@ -1,2 +0,0 @@ -Makefile -Makefile.in diff --git a/doc/COPYING-DOCS b/doc/COPYING-DOCS deleted file mode 100644 index b42936beb3..0000000000 --- a/doc/COPYING-DOCS +++ /dev/null @@ -1,355 +0,0 @@ - GNU Free Documentation License - Version 1.1, March 2000 - - Copyright (C) 2000 Free Software Foundation, Inc. - 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - -0. PREAMBLE - -The purpose of this License is to make a manual, textbook, or other -written document "free" in the sense of freedom: to assure everyone -the effective freedom to copy and redistribute it, with or without -modifying it, either commercially or noncommercially. Secondarily, -this License preserves for the author and publisher a way to get -credit for their work, while not being considered responsible for -modifications made by others. - -This License is a kind of "copyleft", which means that derivative -works of the document must themselves be free in the same sense. It -complements the GNU General Public License, which is a copyleft -license designed for free software. - -We have designed this License in order to use it for manuals for free -software, because free software needs free documentation: a free -program should come with manuals providing the same freedoms that the -software does. But this License is not limited to software manuals; -it can be used for any textual work, regardless of subject matter or -whether it is published as a printed book. We recommend this License -principally for works whose purpose is instruction or reference. - - -1. APPLICABILITY AND DEFINITIONS - -This License applies to any manual or other work that contains a -notice placed by the copyright holder saying it can be distributed -under the terms of this License. The "Document", below, refers to any -such manual or work. Any member of the public is a licensee, and is -addressed as "you". - -A "Modified Version" of the Document means any work containing the -Document or a portion of it, either copied verbatim, or with -modifications and/or translated into another language. - -A "Secondary Section" is a named appendix or a front-matter section of -the Document that deals exclusively with the relationship of the -publishers or authors of the Document to the Document's overall subject -(or to related matters) and contains nothing that could fall directly -within that overall subject. (For example, if the Document is in part a -textbook of mathematics, a Secondary Section may not explain any -mathematics.) The relationship could be a matter of historical -connection with the subject or with related matters, or of legal, -commercial, philosophical, ethical or political position regarding -them. - -The "Invariant Sections" are certain Secondary Sections whose titles -are designated, as being those of Invariant Sections, in the notice -that says that the Document is released under this License. - -The "Cover Texts" are certain short passages of text that are listed, -as Front-Cover Texts or Back-Cover Texts, in the notice that says that -the Document is released under this License. - -A "Transparent" copy of the Document means a machine-readable copy, -represented in a format whose specification is available to the -general public, whose contents can be viewed and edited directly and -straightforwardly with generic text editors or (for images composed of -pixels) generic paint programs or (for drawings) some widely available -drawing editor, and that is suitable for input to text formatters or -for automatic translation to a variety of formats suitable for input -to text formatters. A copy made in an otherwise Transparent file -format whose markup has been designed to thwart or discourage -subsequent modification by readers is not Transparent. A copy that is -not "Transparent" is called "Opaque". - -Examples of suitable formats for Transparent copies include plain -ASCII without markup, Texinfo input format, LaTeX input format, SGML -or XML using a publicly available DTD, and standard-conforming simple -HTML designed for human modification. Opaque formats include -PostScript, PDF, proprietary formats that can be read and edited only -by proprietary word processors, SGML or XML for which the DTD and/or -processing tools are not generally available, and the -machine-generated HTML produced by some word processors for output -purposes only. - -The "Title Page" means, for a printed book, the title page itself, -plus such following pages as are needed to hold, legibly, the material -this License requires to appear in the title page. For works in -formats which do not have any title page as such, "Title Page" means -the text near the most prominent appearance of the work's title, -preceding the beginning of the body of the text. - - -2. VERBATIM COPYING - -You may copy and distribute the Document in any medium, either -commercially or noncommercially, provided that this License, the -copyright notices, and the license notice saying this License applies -to the Document are reproduced in all copies, and that you add no other -conditions whatsoever to those of this License. You may not use -technical measures to obstruct or control the reading or further -copying of the copies you make or distribute. However, you may accept -compensation in exchange for copies. If you distribute a large enough -number of copies you must also follow the conditions in section 3. - -You may also lend copies, under the same conditions stated above, and -you may publicly display copies. - - -3. COPYING IN QUANTITY - -If you publish printed copies of the Document numbering more than 100, -and the Document's license notice requires Cover Texts, you must enclose -the copies in covers that carry, clearly and legibly, all these Cover -Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on -the back cover. Both covers must also clearly and legibly identify -you as the publisher of these copies. The front cover must present -the full title with all words of the title equally prominent and -visible. You may add other material on the covers in addition. -Copying with changes limited to the covers, as long as they preserve -the title of the Document and satisfy these conditions, can be treated -as verbatim copying in other respects. - -If the required texts for either cover are too voluminous to fit -legibly, you should put the first ones listed (as many as fit -reasonably) on the actual cover, and continue the rest onto adjacent -pages. - -If you publish or distribute Opaque copies of the Document numbering -more than 100, you must either include a machine-readable Transparent -copy along with each Opaque copy, or state in or with each Opaque copy -a publicly-accessible computer-network location containing a complete -Transparent copy of the Document, free of added material, which the -general network-using public has access to download anonymously at no -charge using public-standard network protocols. If you use the latter -option, you must take reasonably prudent steps, when you begin -distribution of Opaque copies in quantity, to ensure that this -Transparent copy will remain thus accessible at the stated location -until at least one year after the last time you distribute an Opaque -copy (directly or through your agents or retailers) of that edition to -the public. - -It is requested, but not required, that you contact the authors of the -Document well before redistributing any large number of copies, to give -them a chance to provide you with an updated version of the Document. - - -4. MODIFICATIONS - -You may copy and distribute a Modified Version of the Document under -the conditions of sections 2 and 3 above, provided that you release -the Modified Version under precisely this License, with the Modified -Version filling the role of the Document, thus licensing distribution -and modification of the Modified Version to whoever possesses a copy -of it. In addition, you must do these things in the Modified Version: - -A. Use in the Title Page (and on the covers, if any) a title distinct - from that of the Document, and from those of previous versions - (which should, if there were any, be listed in the History section - of the Document). You may use the same title as a previous version - if the original publisher of that version gives permission. -B. List on the Title Page, as authors, one or more persons or entities - responsible for authorship of the modifications in the Modified - Version, together with at least five of the principal authors of the - Document (all of its principal authors, if it has less than five). -C. State on the Title page the name of the publisher of the - Modified Version, as the publisher. -D. Preserve all the copyright notices of the Document. -E. Add an appropriate copyright notice for your modifications - adjacent to the other copyright notices. -F. Include, immediately after the copyright notices, a license notice - giving the public permission to use the Modified Version under the - terms of this License, in the form shown in the Addendum below. -G. Preserve in that license notice the full lists of Invariant Sections - and required Cover Texts given in the Document's license notice. -H. Include an unaltered copy of this License. -I. Preserve the section entitled "History", and its title, and add to - it an item stating at least the title, year, new authors, and - publisher of the Modified Version as given on the Title Page. If - there is no section entitled "History" in the Document, create one - stating the title, year, authors, and publisher of the Document as - given on its Title Page, then add an item describing the Modified - Version as stated in the previous sentence. -J. Preserve the network location, if any, given in the Document for - public access to a Transparent copy of the Document, and likewise - the network locations given in the Document for previous versions - it was based on. These may be placed in the "History" section. - You may omit a network location for a work that was published at - least four years before the Document itself, or if the original - publisher of the version it refers to gives permission. -K. In any section entitled "Acknowledgements" or "Dedications", - preserve the section's title, and preserve in the section all the - substance and tone of each of the contributor acknowledgements - and/or dedications given therein. -L. Preserve all the Invariant Sections of the Document, - unaltered in their text and in their titles. Section numbers - or the equivalent are not considered part of the section titles. -M. Delete any section entitled "Endorsements". Such a section - may not be included in the Modified Version. -N. Do not retitle any existing section as "Endorsements" - or to conflict in title with any Invariant Section. - -If the Modified Version includes new front-matter sections or -appendices that qualify as Secondary Sections and contain no material -copied from the Document, you may at your option designate some or all -of these sections as invariant. To do this, add their titles to the -list of Invariant Sections in the Modified Version's license notice. -These titles must be distinct from any other section titles. - -You may add a section entitled "Endorsements", provided it contains -nothing but endorsements of your Modified Version by various -parties--for example, statements of peer review or that the text has -been approved by an organization as the authoritative definition of a -standard. - -You may add a passage of up to five words as a Front-Cover Text, and a -passage of up to 25 words as a Back-Cover Text, to the end of the list -of Cover Texts in the Modified Version. Only one passage of -Front-Cover Text and one of Back-Cover Text may be added by (or -through arrangements made by) any one entity. If the Document already -includes a cover text for the same cover, previously added by you or -by arrangement made by the same entity you are acting on behalf of, -you may not add another; but you may replace the old one, on explicit -permission from the previous publisher that added the old one. - -The author(s) and publisher(s) of the Document do not by this License -give permission to use their names for publicity for or to assert or -imply endorsement of any Modified Version. - - -5. COMBINING DOCUMENTS - -You may combine the Document with other documents released under this -License, under the terms defined in section 4 above for modified -versions, provided that you include in the combination all of the -Invariant Sections of all of the original documents, unmodified, and -list them all as Invariant Sections of your combined work in its -license notice. - -The combined work need only contain one copy of this License, and -multiple identical Invariant Sections may be replaced with a single -copy. If there are multiple Invariant Sections with the same name but -different contents, make the title of each such section unique by -adding at the end of it, in parentheses, the name of the original -author or publisher of that section if known, or else a unique number. -Make the same adjustment to the section titles in the list of -Invariant Sections in the license notice of the combined work. - -In the combination, you must combine any sections entitled "History" -in the various original documents, forming one section entitled -"History"; likewise combine any sections entitled "Acknowledgements", -and any sections entitled "Dedications". You must delete all sections -entitled "Endorsements." - - -6. COLLECTIONS OF DOCUMENTS - -You may make a collection consisting of the Document and other documents -released under this License, and replace the individual copies of this -License in the various documents with a single copy that is included in -the collection, provided that you follow the rules of this License for -verbatim copying of each of the documents in all other respects. - -You may extract a single document from such a collection, and distribute -it individually under this License, provided you insert a copy of this -License into the extracted document, and follow this License in all -other respects regarding verbatim copying of that document. - - -7. AGGREGATION WITH INDEPENDENT WORKS - -A compilation of the Document or its derivatives with other separate -and independent documents or works, in or on a volume of a storage or -distribution medium, does not as a whole count as a Modified Version -of the Document, provided no compilation copyright is claimed for the -compilation. Such a compilation is called an "aggregate", and this -License does not apply to the other self-contained works thus compiled -with the Document, on account of their being thus compiled, if they -are not themselves derivative works of the Document. - -If the Cover Text requirement of section 3 is applicable to these -copies of the Document, then if the Document is less than one quarter -of the entire aggregate, the Document's Cover Texts may be placed on -covers that surround only the Document within the aggregate. -Otherwise they must appear on covers around the whole aggregate. - - -8. TRANSLATION - -Translation is considered a kind of modification, so you may -distribute translations of the Document under the terms of section 4. -Replacing Invariant Sections with translations requires special -permission from their copyright holders, but you may include -translations of some or all Invariant Sections in addition to the -original versions of these Invariant Sections. You may include a -translation of this License provided that you also include the -original English version of this License. In case of a disagreement -between the translation and the original English version of this -License, the original English version will prevail. - - -9. TERMINATION - -You may not copy, modify, sublicense, or distribute the Document except -as expressly provided for under this License. Any other attempt to -copy, modify, sublicense or distribute the Document is void, and will -automatically terminate your rights under this License. However, -parties who have received copies, or rights, from you under this -License will not have their licenses terminated so long as such -parties remain in full compliance. - - -10. FUTURE REVISIONS OF THIS LICENSE - -The Free Software Foundation may publish new, revised versions -of the GNU Free Documentation License from time to time. Such new -versions will be similar in spirit to the present version, but may -differ in detail to address new problems or concerns. See -http://www.gnu.org/copyleft/. - -Each version of the License is given a distinguishing version number. -If the Document specifies that a particular numbered version of this -License "or any later version" applies to it, you have the option of -following the terms and conditions either of that specified version or -of any later version that has been published (not as a draft) by the -Free Software Foundation. If the Document does not specify a version -number of this License, you may choose any version ever published (not -as a draft) by the Free Software Foundation. - - -ADDENDUM: How to use this License for your documents - -To use this License in a document you have written, include a copy of -the License in the document and put the following copyright and -license notices just after the title page: - - Copyright (c) YEAR YOUR NAME. - Permission is granted to copy, distribute and/or modify this document - under the terms of the GNU Free Documentation License, Version 1.1 - or any later version published by the Free Software Foundation; - with the Invariant Sections being LIST THEIR TITLES, with the - Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. - A copy of the license is included in the section entitled "GNU - Free Documentation License". - -If you have no Invariant Sections, write "with no Invariant Sections" -instead of saying which ones are invariant. If you have no -Front-Cover Texts, write "no Front-Cover Texts" instead of -"Front-Cover Texts being LIST"; likewise for Back-Cover Texts. - -If your document contains nontrivial examples of program code, we -recommend releasing these examples in parallel under your choice of -free software license, such as the GNU General Public License, -to permit their use in free software. diff --git a/doc/Camel-Classes b/doc/Camel-Classes deleted file mode 100644 index 8b510dad7a..0000000000 --- a/doc/Camel-Classes +++ /dev/null @@ -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 diff --git a/doc/ChangeLog b/doc/ChangeLog deleted file mode 100644 index e69de29bb2..0000000000 --- a/doc/ChangeLog +++ /dev/null diff --git a/doc/ChangeLog.pre-1-4 b/doc/ChangeLog.pre-1-4 deleted file mode 100644 index e7dd37db31..0000000000 --- a/doc/ChangeLog.pre-1-4 +++ /dev/null @@ -1,1146 +0,0 @@ -2001-08-16 Kjartan Maraas <kmaraas@gnome.org> - - * C/Makefile.am: Small fix to build. - * C/evolution-C.omf: Small fix. Remove an extra space. - * no/Makefile.am: Same here. - * no/evolution-no.omf: And here. - -2001-08-15 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Updated one line about bullet points. - -2001-08-15 Kjartan Maraas <kmaraas@gnome.org> - - * no/*: Added beginnings of a Norwegian translation. - * sgmldocs.make: Forgot to add this. Kinda important. - * C/*.sgml: s/fig/figures/ - * C/Makefile.am: Make it use the sgmldocs.make framework. - -2001-08-14 Aaron Weber <aaron@ximian.com> - - * C/usage-mainwindow.sgml: Commented out menuref. - * C/usage-contact.sgml: Commented out menuref. - * C/evolution.sgml: commented out menuref. - * C/preface.sgml: commented out menuref. - -2001-08-12 Kjartan Maraas <kmaraas@gnome.org> - - * C/apx-authors.sgml: Added missing ;'s after entities. - * C/evolution-C.omf: s/en/C in Language. - * C/usage-mail-org.sgml: Add missing ;. - * C/usage-mainwindow.sgml: Same here. - -2001-08-10 Aaron Weber <aaron@ximian.com> - - * C/usage-mail.sgml: Switched all images in entire document to - *not* use file extensions, so that they work properly with - db2ps. This doesn't completely fix the db2ps issues, but it's - apparently the right way to do this. - -2001-08-09 Aaron Weber <aaron@ximian.com> - - * C/config-prefs.sgml: Made sharing tip an orderedlist. - -2001-08-08 Kevin Breit <battery841@mediaone.net> - - * C/config-prefs.sgml: Add information about sharing mailbox files. - -2001-08-03 Kevin Breit <battery841@mediaone.net> - - * C/usage-calendar.sgml: Add information about gathering actions. - -2001-08-02 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Added a <tip> for scrolling through mails. - -2001-07-30 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Fixed some breakage Aaron caused. - -2001-07-26 Aaron Weber <aaron@ximian.com> - - * C/usage-mail-org.sgml: revised. - - * C/usage-mail.sgml: revisions and stuff. - -2001-07-24 Aaron Weber <aaron@ximian.com> - - * C/evolution-faq.sgml: Reworded a few questions. - -2001-07-23 Kevin Breit <battery841@mediaone.net> - - * C/Makefile.am: Pulled instance of config-setupassist.sgml to make stuff build right. - -2001-07-23 Aaron Weber <aaron@ximian.com> - - * C/usage-mainwindow.sgml: validated. - - * C/config-setupassist.sgml: Removed. - - * C/evolution.sgml: removed config-setupassist. - - * C/usage-exec-summary.sgml: Minor revisions. - - * C/usage-contact.sgml: Added 'format="png"' to all <image> tags - missing the attribute. - - * C/usage-calendar.sgml: Added 'format="png"' to all <image> tags - missing the attribute. - - * C/usage-mail.sgml: Added 'format="png"' to all <image> tags - missing the attribute. - - * C/usage-mainwindow.sgml: Style. Merged info from preface. Added - 'format="png"' to all <image> tags missing the attribute. - - * C/preface.sgml: Style changes. Removed info that was duplicated - in mainwindow.sgml. - -2001-07-20 Kevin Breit <battery841@mediaone.net> - - * C/usage-mainwindow.sgml: Fixed the first time druid stuff a little more. - -2001-07-16 Aaron Weber <aaron@ximian.com> - - * C/evolution-faq.sgml: Sepllcheck. - -2001-07-15 Kevin Breit <battery841@mediaone.net> - - * C/config-sync.sgml: Updated slightly for new design. - -2001-07-13 Kevin Breit <battery841@mediaone.net> - - * C/usage-mainwindow.sgml: Added lots of good stuff with the first time druid. - -2001-07-12 Aaron Weber <aaron@ximian.com> - - * C/evolution-faq.sgml: TYPO fixing. - -2001-07-12 Aaron Weber <aaron@ximian.com> - - * C/evolution-faq.sgml: Added "get bt for component-only crash" qandaentry. - -2001-07-10 Peter Williams <peterw@ximian.com> - - * */Makefile.am (dist-hook): Clean up make dist. - -2001-07-11 Aaron Weber <aaron@ximian.com> - - * C/evolution.sgml: validation on usage-mainwindow and usage-contact. - -2001-07-11 Kevin Breit <battery841@mediaone.net> - - * C/usage-calendar.sgml: More edits. - - * C/usage-contact.sgml: Sick amounts of changes too! - - * C/usage-mail-org.sgml: Heavy editing...touched almost everything. - - * C/usage-exec-summary.sgml: Minor change. There was only one change for this chapter, cuz I'm such a 'godly' writer...yeah. - - * C/usage-mainwindow.sgml: A bit of editing. - - * C/preface.sgml: Screwed with the examples and did some cleanup. - -2001-07-10 Aaron Weber <aaron@ximian.com> - - * C/usage-mail-org.sgml: validation. - -2001-07-10 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Added <application> tags - - * C/usage-mail-org.sgml: Added <application> tags - - * C/config-prefs.sgml: Added <application> tags - -2001-07-09 Kevin Breit <battery841@mediaone.net> - - * C/usage-exec-summary.sgml: Editing - - * C/usage-mail.sgml: Editing - - * C/usage-mail-org.sgml: Editing - - * C/usage-calendar.sgml: Editing - - * C/usage-contact.sgml: Editing - - * C/usage-mail-org.sgml: Mention UNMATCHED - - * C/usage-mail.sgml: Commented on trash being a vFolder - -2001-07-06 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Spell check - - * C/usage-calendar.sgml: Spell check - -2001-07-05 Kevin Breit <battery841@mediaone.net> - - * C/usage-mainwindow.sgml: Added orderedlists. - - * C/usage-exec-summary.sgml: Added orderedlists. - - * C/usage-contact.sgml: Added orderedlists. - - * C/usage-mail-org.sgml: Added orderedlists. - -2001-07-03 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Put in lots of orderedlists...more SGML, less - for the user to read. They'll thank me in droves later. - - * C/usage-exec-summary.sgml: Fixed build error - -2001-06-29 Jeffrey Stedfast <fejj@ximian.com> - - * white-papers/mail/camel.sgml: Updated slightly. - - * Camel-Classes: Updated. - -2001-07-02 Kevin Breit <battery841@mediaone.net> - - * C/apx-common-tasks.sgml: Created its own file. - - * C/usage-mainwindow.sgml: You name it. - - * C/preface.sgml: Pulled shortcuts from here into its own apx - - * C/evolution.sgml: Reordered entities - -2001-06-30 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Pulled organizing stuff, made its own file. - -2001-06-26 Aaron Weber <aaron@ximian.com> - - * C/evolution-faq.sgml: Revised move/rename/copy questions, now - that these functions work. - -2001-06-25 Aaron Weber <aaron@ximian.com> - - * C/evolution-faq.sgml: Now that bug-buddy works with our - bugzilla, update faq to reflect it. - -2001-06-25 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Put config-encryption in usage-mail.sgml. - config-encryption.sgml should be depreciated. - - * C/usage-contact.sgml: Fixed typo - - * C/usage-mail.sgml: Added info about mailing lists Elaborated on - mailing lists - - * C/usage-exec-summary.sgml: Fixed a few typos - - * C/preface.sgml: Added section for importing files - - * C/usage-calendar.sgml: Removed some *'s that are causing - problems. - -2001-06-22 Kevin Breit <battery841@mediaone.net> - - * C/preface.sgml: Put in Contacts information in the quicktasks. - - * C/usage-mail.sgml: Pulled some redundant information. - -2001-06-21 battery841 <battery841@mediaone.net> - - * C/preface.sgml, C/fig/mail-inbox.png, C/fig/mainwindow-pic.png, - C/usage-mail.sgml: Updated screenshots and redid layout for - graphics on pages. - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/usage-contact.sgml: Fixed .gif problem - - * C/usage-mail.sgml: - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Specify the file format - - * C/usage-contact.sgml, C/usage-mail.sgml: - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Trying to fix the .gif problem - - * C/fig/calendar.png, C/fig/contact.png, C/usage-calendar.sgml: - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/usage-calendar.sgml: Redid graphics to add labels to them and - described the labels in text. - - * C/config-encryption.sgml, C/evolution.sgml: - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/evolution.sgml: Added config-encryption.sgml for building - - * C/fig/calendar.png, C/fig/config-cal.png, C/fig/config-mail.png, - C/fig/filter-assist-fig.png, C/fig/filter-new-fig.png, - C/fig/mail-composer.png, C/fig/mail-druid-pic.png, - C/fig/mail-inbox.png, C/fig/print-dest.png, - C/fig/print-preview.png, C/fig/vfolder-createrule-fig.png: - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/fig/*png: Updated graphics for newer UI. - - * C/fig/full-1.png, C/fig/full-2.png, C/fig/full-3.png, - C/fig/full-4.png, C/fig/full-5.png, C/fig/full-6.png, - C/fig/full-7.png, C/fig/mainwindow-pic.png, C/usage-mail.sgml: - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Redid graphics to add labels to them and - described in labels in text. Looks good! - - * C/usage-encryption.sgml: - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/encryption.sgml: Added file - - * C/preface.sgml: - -2001-06-20 Kevin Breit <battery841@mediaone.net> - - * doc/ChangeLog: Moved my entires to doc/ChangeLog per request of - danw - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/usage-contact.sgml: Fixed .gif problem - - * C/usage-mail.sgml: Specify the file format - - * C/usage-mail.sgml: Trying to fix the .gif problem - - * C/usage-calendar.sgml: Redid graphics to add labels to them and - described the labels in text. - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/evolution.sgml: Added config-encryption.sgml for building - - * C/fig/*png: Updated graphics for newer UI. - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Redid graphics to add labels to them and - described in labels in text. Looks good! - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: - -2001-06-21 Kevin Breit <battery841@mediaone.net> - - * C/encryption.sgml: Added file - -2001-06-20 Kevin Breit <battery841@mediaone.net> - - * ChangeLog: Moved my entires to doc/ChangeLog per request of danw - -2001-06-20 Kevin Breit <battery841@mediaone.net> - - * C/config-setupassist.sgml: Updated for new UI. - -2001-06-20 Kevin Breit <battery841@mediaone.net> - - * C/usage-sync: Reworded a little bit for more descrip. - -2001-06-20 Kevin Breit <battery841@mediaone.net> - - * C/usage-calendar.sgml: Documented categorizing an event. - -2001-06-20 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Updated Bcc: example - -2001-06-19 Aaron Weber <aaron@ximian.com> - - * C/usage-mainwindow.sgml: A couple changes to Kevin's update. - -2001-06-19 Kevin Breit <battery841@mediaone.net> - - * C/usage-mail.sgml: Basic edits - -2001-06-19 Kevin Breit <battery841@mediaone.net> - - * C/usage-exec-summary: Updated to say "My Evolution" - -2001-06-19 Kevin Breit <battery841@mediaone.net> - - * C/apx-gloss.sgml: Added definition. - - * C/usage-mainwindow.sgml: Routine updates. - -2001-06-07 Duncan Mak <duncan@lumox.simplemente.net> - - * C/evolution-faq.sgml: Fixed a typo. Thanks to Greg Leblanc for - pointing this out. - -2001-05-23 Ettore Perazzoli <ettore@ximian.com> - - * C/evolution-faq.sgml: Re-indented. - -2001-05-18 Duncan Mak <duncan@ximian.com> - - * C/evolution-faq.sgml: Added two questions about importing - Outlook (text from Iain). Fixed some tags and cleaned up a bit - here and there. - -2001-05-18 Ettore Perazzoli <ettore@ximian.com> - - * C/evolution-faq.sgml: Added a question about the permission - issues with /var/spool/mail. - -2001-05-15 Ettore Perazzoli <ettore@ximian.com> - - * C/Makefile.am (SGML_FILES): Renamed to `GUIDE_SGML_FILES'. - (EXTRA_DIST): Add `$(FAQ_SGML_FILES)'. - (all): Depend on `evolution-faq' too. - (evolution-faq): New. - (install-data-local): Depend on `evolution-faq' too. Install the - FAQ into `$(evolution_helpdir)/evolution-faq' and the guide into - `$(evolution_helpdir)/evolution-guide'. - - * C/evolution-faq.sgml: New. - -2001-04-23 Jon Trowbridge <trow@ximian.com> - - * C/Makefile.am (install-data-local): Changed dependency for - install-data-local from "evolution" to "evolution-guide". - -2001-04-23 Ettore Perazzoli <ettore@ximian.com> - - * C/Makefile.am (evolution-guide): Use `$(srcdir)' here. - -2001-04-23 Ettore Perazzoli <ettore@ximian.com> - - * C/Makefile.am (SGML_FILES): Add `evolution.sgml'. - (evolution-guide): Process `evolution.sgml', not - `evolution-guide.sgml'. - (dist-hook): s/evolution-guide/evolution/ - (install-data-local): Likewise. - -2001-02-23 Aaron Weber <aaron@helixcode.com> - - * C/apx-authors.sgml: s/helixcode/ximian (How I missed this page - on the first go-round I don't know). - -2001-03-14 Gediminas Paulauskas <menesis@delfi.lt> - - * C/Makefile.am: there's no apx-fdl.sgml and evolution-guide.sgml - anymore - -2001-02-23 Aaron Weber <aaron@helixcode.com> - - * C/usage-mail.sgml: IMAP subscriptions stuff. - -2001-02-21 Aaron Weber <aaron@helixcode.com> - - * C/usage-mail.sgml: Advanced search/show all/save search stuff. - - * C/evolution.sgml: This file replaces evolution-guide.sgml, for - Nautilus Readiness. - - * C/apx-gloss.sgml: glossterm conduit. - - * C/config-sync.sgml: Glossterm conduit. - - * C/preface.sgml: Checked over for Keyboard-Shortcut and other - truthfulness. - -2001-02-15 Aaron Weber <aaron@helixcode.com> - - * C/evolution-guide.sgml: Validated. Verified. Markup fixed in - several individual files. - - * C/apx-gpl.sgml: cvs-removed for GNOME 1.4 compliance. - - * C/apx-fdl.sgml: cvs-removed for GNOME 1.4 compliance. - -2001-02-09 Aaron Weber <aaron@helixcode.com> - - * C/config-sync.sgml: Overhaul. Now accurate and truthful and - clear. - - * C/usage-calendar.sgml: Minor Changes. - -2001-02-08 Aaron Weber <aaron@helixcode.com> - - * C/usage-contact.sgml: Minor Changes. - - * C/usage-mail.sgml: Minor Changes. - -2001-02-07 Aaron Weber <aaron@helixcode.com> - - * C/menuref.sgml: Added section, but left blank til UI stabilizes. - - * C/usage-exec-summary.sgml: A little functionality described. - - * C/usage-mainwindow.sgml: Added tasks and Exec-summary. - - * C/usage-calendar.sgml: Describe semi-autonomy of task pad. - -2001-02-06 Aaron Weber <aaron@ximian.com> - - * C/usage-contact.sgml: s/contact manager/address book/ and - revised text. - - * C/usage-exec-summary.sgml: New file. Describes Executive - Summary. - -2001-01-19 Aaron Weber <aaron@helixcode.com> - - * C/usage-mail.sgml: More of Megan's revisions, and Field Chooser - functions in the Sort section. - - * C/apx-gloss.sgml: added "ToolTip" - -2001-01-18 Aaron Weber <aaron@helixcode.com> - - * C/preface.sgml: s/Helix Code/Ximian, and Megan's comments. - - * C/usage-mainwindow.sgml: s/Helix Code/Ximian/, and Megan's - comments. - - * C/evolution-guide.sgml: s/Helix Code/Ximian/ - -2000-12-13 Aaron Weber <aaron@helixcode.com> - - * C/usage-mail.sgml: Revisions as suggested by Dan. Especially to - filter dialogs... which still need some renaming, IMHO. - - * C/usage-mainwindow.sgml: Revisions as suggested by - Dan. Especially to the Folder Limits thing, which still upsets me - somehow. - - * C/preface.sgml: Revisions as suggested by Dan. - -2000-11-29 Aaron Weber <aaron@helixcode.com> - - * C/config-setupassist.sgml: added some <glossterms>, added - linkends to existing glossterms. - -2000-11-28 Aaron Weber <aaron@helixcode.com> - - * C/evolution-guide.sgml: Changed intro to Config section. Now - defines what, exactly, "configurable" means. - - * C/usage-print.sgml: Stylistic revisions. - - * C/usage-calendar.sgml: Stylistic revisions. - - * C/usage-contact.sgml: Stylistic revisions. - -2000-11-09 Aaron Weber <aaron@helixcode.com> - - * C/menuref.sgml: Message heading Right-Click Menu. - -2000-11-03 Aaron Weber <aaron@helixcode.com> - - * C/apx-gloss.sgml: The regexp example was quite wrong. Props to - Sasha. - -2000-11-02 Aaron Weber <aaron@helixcode.com> - - * C/usage-contact.sgml: Style and spelling. - -2000-11-01 Aaron Weber <aaron@helixcode.com> - - * C/config-prefs.sgml: Fixed validation errors. - - * C/apx-gloss.sgml: Fixed HTML, style stuff. - - * C/usage-mail.sgml: Stylistic overhaul. - - * C/usage-mainwindow.sgml: Fixed groups in shortcut bar, fixed - folder navigation tips. - -2000-10-31 Aaron Weber <aaron@helixcode.com> - - * C/preface.sgml: Minor stylistic revisions. - -2000-10-30 Aaron Weber <aaron@helixcode.com> - - * COPYING-DOCS: New file. This is the official place to put the - FDL now. - - -2000-11-01 Radek Doulik <rodo@helixcode.com> - - * Keybindings: added composer keybindings description - -2000-10-25 Aaron Weber <aaron@helixcode.com> - - * C/menuref.sgml: Actions -> New Directory Server added. - - * C/config-prefs.sgml: Actions -> New Directory Server added. - - * C/usage-contact.sgml: Actions -> New Directory Server added. - - * C/menuref.sgml: Added mail Settings->Manage Subscriptions menu. - - * C/usage-mail.sgml: Subscriptions section added. Quite - incomplete, though. - -2000-10-11 Aaron Weber <aaron@helixcode.com> - - * C/evolution-guide.sgml: Re-checked validity of all files. Made - minor changes to menuref.sgml, usage-mail.sgml, usage-print.sgml - to bring up to spec. - - * C/usage-mail.sgml: Redid Filter & Vfolder to match the new & - improved functionality. - - * C/fig/*: Re-did remaining screenshots. - -2000-10-10 Aaron Weber <aaron@helixcode.com> - - * C/usage-print.sgml: New file, describing printing and - print-preview. - - * C/fig/print-preview.png: New file. - - * C/fig/print-dest.png: New file. - - * C/evolution-guide.sgml: Added usage-print entity. - - * C/menuref.sgml: Fixed calendar menu stuff. - - * C/usage-mail.sgml: No more "Actions" menu, other assorted - menu-related changes. - -2000-10-06 Aaron Weber <aaron@helixcode.com> - - * C/fig/ * replaced a whole bunch of screenshots. - -2000-10-05 Aaron Weber <aaron@helixcode.com> - - * C/usage-contact.sgml: Described Search features. - - * C/menuref.sgml: Contact Manager menus fixed. - -2000-10-04 Aaron Weber <aaron@helixcode.com> - - * C/usage-contact.sgml: Fixed glossterms. - - * C/usage-mail.sgml: Fixed glossterms, filenames, spellchecked. - - * C/apx-gloss.sgml: Added "Inline," "VCard". - - * C/usage-mainwindow.sgml: Fixed glossterms, - filenames. Spellchecked. - - * C/usage-mail.sgml: Fixed glossterms, filenames. Spellchecked. - - * C/evolution-guide.sgml: New Legalnotice. Removed FDL and GPL, - which are now included as part of the gnome-help package. - - * C/usage-contact.sgml: Spellcheck. Fixed some wording, and - responded to clahey's suggestions-- notably, commented out the - "add to master list" category feature. - - * C/usage-calendar.sgml: Spellcheck. Fixed wording, event overlap - description. - - * C/evolution-guide.sgml: Spellcheck. Commented out Notes - entities. - - * C/usage-notes.sgml: Spellchecked, then decided to comment out - this file/chapter and all references to it, since it's unlikely to - be implemented any time soon. - - * C/config-setupassist.sgml: Spellcheck. Other minor updates. May - need more work in the near future. - - * C/usage-sync.sgml: Now it's really short. And spelled correctly. - -2000-10-03 Aaron Weber <aaron@helixcode.com> - - * C/config-prefs.sgml: Mostly spelling. Still needs major - alteration. - - * C/menuref.sgml: s/Appintment/Appointment, fixed small errors, - ran spellcheck. Still needs lots of work, since many menus have - changed. - - * C/apx-gloss.sgml: Added Virus, Protocol, fixed vFolder, - spellchecked. - -2000-09-26 Aaron Weber <aaron@helixcode.com> - - * C/apx-gloss.sgml: Added sendmail and SMTP. - -2000-09-22 Aaron Weber <aaron@helixcode.com> - - * C/menuref.sgml: Changed to reflect new menu layout. - - * C/usage-mainwindow.sgml: Changed to reflect new menu - layout. Again. - - * C/usage-contact.sgml: Stop and Display All features. - -2000-09-21 Aaron Weber <aaron@helixcode.com> - - * C/evolution-guide.sgml: Switched to the "official" FSF markup. - I will have to make changes to the markup-- adding ids, etc, or - switch to another version of the markup. Pending discussion by - GDP. - - * C/apx-authors.sgml: Changed Matt Loper's email address to - loper.org; added Jeff Stedfast and Peter Williams to authors list, - realphebetized. - - * C/config-prefs.sgml: Revision to reflect current options - labelling. - - * C/evolution-guide.sgml: Changes to part intros. - - * C/preface.sgml: Spelling and menu fixes. Will need more work - tomorrow. - -2000-09-20 Aaron Weber <aaron@helixcode.com> - - * C/config-prefs.sgml: Fixed sig stuff here and in setupassist. - - * C/config-sync.sgml: Fixed description of conduit usage. - -2000-09-18 Aaron Weber <aaron@helixcode.com> - - * C/preface.sgml: Spelling fixes, etc. - -2000-09-19 Federico Mena Quintero <federico@helixcode.com> - - * C/Makefile.am: Fixed to install the stylesheet-images as well. - -2000-09-07 Aaron Weber <aaron@helixcode.com> - - * C/fig/ New files: contact-editor.png, mail-composer.png, - filter-assist-fig.png, mail-inbox.png - -2000-09-07 Aaron Weber <aaron@helixcode.com> - - * C/preface.sgml: Redid "soft" intro stuff. - - * C/evolution-guide.sgml: Accidentally broke docs, now valid. - -2000-09-06 Aaron Weber <aaron@helixcode.com> - - * C/usage-contact.sgml: Editing, proofing. - -2000-09-05 Aaron Weber <aaron@helixcode.com> - - * C/usage-contact.sgml: Grammar, links, screenshots. - - * fig/* Re-took most screenshots. - - * C/usage-mail.sgml: Filters, proofing. - -2000-09-01 Aaron Weber <aaron@helixcode.com> - - * C/config-prefs.sgml: Added coverage of news, clarified POP/IMAP - distinction (there's a theme to these four log entries here). - - * C/usage-mail.sgml: Added coverage of news. - - * C/config-setupassist.sgml: Revised mail sources content for - IMAP/POP stuff. - - * C/apx-gloss.sgml: Added IMAP and POP. - -2000-08-31 Aaron Weber <aaron@helixcode.com> - - * C/apx-gloss.sgml: Added regular expressions to glossary. - Explanation should be removed from other portions of the book now. - - * C/usage-mainwindow.sgml: Revisions, minor. - - * C/apx-menuref.sgml: Now named menuref.sgml, to reflect its new - status as a part. - - * C/evolution-guide.sgml: Structural alterations: Menuref is now a - part, not an appendix. - - * C/apx-menuref.sgml: Added contextual menus for mail. - - * C/preface.sgml: Added "quickref and pointers" sections. Props to - O'Reilly for the copy of Outlook in a Nutshell which gave me the - idea. - -2000-08-30 Aaron Weber <aaron@helixcode.com> - - * C/usage-mainwindow.sgml: Minor fixes. - - * C/preface.sgml: Corrected grammar, added glossterms, described - menuref. - -2000-08-25 Aaron Weber <aaron@helixcode.com> - - * C/usage-mail.sgml: Redid filter and vFolder assistant - descriptions. - - * C/fig/filter-new-fig.png: Replaced with new assistant pic. - - * C/fig/filter-assist-fig.png: New file, showing only assistant. - - - * C/apx-menuref.sgml: Finished message composer and calendar - editor menus. Looked at Contact Editor menus and decided to - document those features after implementation. - -2000-08-24 Aaron Weber <aaron@helixcode.com> - - * C/apx-menuref.sgml: Message Composer File and Edit menus. - -2000-08-23 Aaron Weber <aaron@helixcode.com> - - * C/apx-menuref.sgml: Added editor sections. - - * C/evolution-guide.sgml: Included Menu Reference Appendix. - -2000-08-22 Aaron Weber <aaron@helixcode.com> - - * C/usage-mail.sgml: Minor markup changes. - - * C/apx-menuref.sgml: New File. Menu Reference. Still needs much - work, but not bad for an evening. - -2000-08-21 Aaron Weber <aaron@helixcode.com> - - * C/usage-mail.sgml: Kevin's diff applied, with minor changes. - -2000-08-09 Aaron Weber <aaron@helixcode.com> - - * C/evolution-guide.sgml: Fixed bugs in validation. Went home to - sleep. - - * C/usage-mainwindow.sgml: Redid menubar description. - - - * C/config-prefs.sgml: Added coverage of folder config, requested - that feature be transferred to config section. Switched to - variablelist in "Other" config section. - - * C/usage-mail.sgml: Added coverage of right-click on messages, - threaded-view. - - * C/usage-mainwindow.sgml: Right-click on folder menu reinstated. - -2000-08-07 Aaron Weber <aaron@helixcode.com> - - * C/config-prefs.sgml: Added news server coverage. Other config - proofing changes. - - -2000-08-05 Aaron Weber <aaron@helixcode.com> - - * C/apx-gpl.sgml: New file. Contains contents of "COPYING", but - marked up (probably not very well, but valid) as docbook - (SGML). - - * C/evolution-guide.sgml: Subtle change to the legal notice: - distinguished manual license from software license. Linked to - apx-gpl.sgml above. - - * C/usage-calendar.sgml: I redid all the usage files. - -2000-07-21 Aaron Weber <aaron@helixcode.com> - - * C/usage-mail.sgml: Added password remembering/forgetting - feature. - - * C/config-prefs.sgml: Mostly moved to variablelists, a few - language changes. - - * C/config-setupassist.sgml: Minor changes to formatting, wording. - - * C/usage-notes.sgml: Changed trademark references, other minor - changes. - - * C/usage-calendar.sgml: Minor fixes, added additional calendar - section, removed references to unimplemented features. Spellcheck, - prep for 0.3 release. - -2000-07-19 Aaron Weber <aaron@helixcode.com> - - * C/usage-mail.sgml: lots of minor fixes to language. added - desc. of clahey's cool button-address thing. - - * C/usage-mainwindow.sgml: fixed itemizedlists, ch. to shortcut - bar & folder descs, removed refs to trash. - -2000-07-18 Aaron Weber <aaron@helixcode.com> - - * C/usage-contact.sgml: Altered category addition stuff, plus - suggestions from Kevin. - - * C/apx-gloss.sgml: Added ldap and signature definitions (from - Kevin). - - * C/usage-mail.sgml: Move to variablelists from itemizedlists. - -2000-07-14 Aaron Weber <aaron@helixcode.com> - - * C/usage-contact.sgml: moved to variablelists from itemizedlists - * C/usage-calendar.sgml: moved to variablelists from itemizedlists - -2000-06-29 Aaron Weber <aaron@helixcode.com> - - * C/preface.sgml: Minor fixes. - - * C/usage-notes.sgml: New File for feature that is yet to come. - * C/evolution-guide.sgml: Added entity for notes chapter. - * C/usage-mainwindow.sgml: Un-commented references to notes section. - - * C/apx-authors.sgml: Removed dcm from author list. - - * C/usage-calendar.sgml: Added to-do list features. - -2000-06-28 Aaron Weber <aaron@helixcode.com> - - * C/usage-contact.sgml: commented out future features; redid - contact editor stuff. - - * C/apx-gloss.sgml: Removed "live doc" and added "minicard" - -2000-06-27 Aaron Weber <aaron@helixcode.com> - - * C/devel-action.sgml: Removed file. - * C/devel-script.sgml: Same. - * C/devel-component.sgml: Same. - * C/preface.sgml: Removed references to devel section. - * C/evolution-guide.sgml: Removed references to devel section. - -2000-06-23 Aaron Weber <aaron@helixcode.com> - - * C/evolution-guide.sgml: Made moderate to major stylistic updates - to this, apx-gloss.sgml, and to all files beginning with "usage," - especially wrt HTML mail. - - -2000-06-15 Aaron Weber <aaron@helixcode.com> - - * C/usage-contact.sgml: Category stuff improved. - - * C/usage-calendar.sgml: Now covers how to add an event properly. - -2000-07-17 Federico Mena Quintero <federico@helixcode.com> - - * Makefile.am (SUBDIRS): Added the devel directory. - -2000-06-28 Peter Williams <peterw@curious-george.helixcode.com> - - * C/Makefile.am (SGML_FILES): Don't depend on the newly-removed - devel-*.sgml files. - -2000-06-16 Damon Chaplin <damon@helixcode.com> - - * C/.cvsignore: added evolution-guide and evolution-guide.junk - so we don't get the '? doc/C/evolution-guide' messages each time we - do a cvs update. - -2000-06-14 Aaron Weber <aaron@helixcode.com> - - * C/usage-mainwindow.sgml: added sect on menubar, other minor changes. - - * C/usage-mail.sgml: Improved filter and vfolder - description, and some minor changes from me and Kevin. - -2000-06-07 Aaron Weber <aaron@helixcode.com> - - * C/config-prefs.sgml: finished adding calendar prefs. screenshots. - * C/fig/config-cal.png: new file (screenshot for above) - * C/fig/config-mail.png: same - -2000-06-05 Aaron Weber <aaron@helixcode.com> - - * C/usage-calendar.sgml: Incorporated chgs from Kevin. - - * C/config-prefs.sgml: began total overhaul of structure and added - content reflecting new prefs items. needs LOTS more work. - - * C/usage-mail.sgml: changed some references to id's in the - config-prefs section. - - * C/fig/config-mail.png: changed filename from config-prefs.png - -2000-06-01 Aaron Weber <aaron@helixcode.com> - - * C/config-prefs.sgml: filename was wrong, altered. - - * C/usage-mail.sgml: improved filter instructions, vFolder - instructions. still need work though. - - - * C/usage-contact.sgml: added screenshot. - - * C/usage-calendar.sgml: added screenshot. - - * C/config-prefs.sgml: added screenshots, and now describes the - actual prefs dialogs. - - * C/fig/config-camel.png: new (screenshot) file - * C/fig/filter-druid.png: same - * C/fig/vfolder-druid.png: same - * C/fig/calendar.png: same - * C/fig/contact.png: same - * C/fig/vfolder-createrule-fig.png: same - * C/fig/filter-new-fig.png: same - * C/fig/config-camel.png: same - -2000-06-01 Dan Winship <danw@helixcode.com> - - * Makefile.am: recurse into the C directory - - * C/Makefile.am: Rules to build and install the docs. Mostly - stolen from gnomecal. Only works if you have GDP stuff - (http://www.gnome.org/gdp/) set up on your machine, but won't make - the build fail if you don't. - -2000-05-29 Aaron Weber <aaron@helixcode.com> - - * C/usage-contact.sgml: incorporated kevins notes. - * C/usage-mainwindow.sgml: incorporated kevins notes. - -2000-05-27 Aaron Weber <aaron@helixcode.com> - - * C/evolution-guide.sgml: added Kevin Breit to author and - copyright. - - * C/apx-authors.sgml: Put app authors in a simplelist. - - * C/usage-mail.sgml: Removed USAGE-SETUP insertion, added xref to send - users to config-setupassist chapter. This and the following changes - take setup druid coverage out of usage - section and put it in config section. - * C/config-setupassist.sgml: Added mail druid coverage from - usage-setup.sgml. - * C/usage-setup.sgml: Removed file. contents in - config-setupassist.sgml. - * C/evolution-guide.sgml: Removed - USAGE-SETUP entity (and file usage-setup.sgml.) - - -2000-05-26 Aaron Weber <aaron@helixcode.com> - - * C/fig/mainwindow-pic.png: new file - * C/fig/mail-druid-pic.png: new file - * C/fig: New directory, for figure graphics. - - * C/apx-gloss.sgml: new file. glossary. thx. to kevin from chicago. - - * C/usage-setup.sgml: More accurate description of druid, and - moved to mail section-- see usage-mail.sgml entry. This is a new - location for this entity, and it may move more later. - - - * C/usage-mainwindow.sgml: altered description of starting - evolution. added screenshot for main-window picture. - - * C/usage-mail.sgml: added screenshots, added coverage of setup - druid and put it into get-and-send section, which is probably not - where it should stay. Also started filter druid coverage and - clarified examples, esp. in Bcc: section. - - * C/usage-contact.sgml: Clarified examples. - - * C/preface.sgml: rewording of "what is" and "about book" sections. - - * C/evolution-guide.sgml: added glossary entity APX-GLOSS, altered - phrasing in part intros, changed order of Setup-assistant section. - - * C/config-prefs.sgml: changed wording, removed ref. to re-running - setup assistant. - -2000-05-18 Aaron Weber <aaron@helixcode.com> - - * C/evo_book_0.1.sgml: removed. - - * C/apx-authors.sgml: new file. - * C/apx-bugs.sgml: same. - * C/apx-fdl.sgml: same. - * C/config-prefs.sgml: same. - * C/config-setupassist.sgml: same. - * C/config-sync.sgml: same. - * C/devel-action.sgml: same. - * C/devel-component.sgml: same. - * C/devel-script.sgml: same. - * C/evolution-guide.sgml: same. - * C/preface.sgml: same. - * C/usage-calendar.sgml: same. - * C/usage-contact.sgml: same. - * C/usage-mail.sgml: same. - * C/usage-mainwindow.sgml: same. - * C/usage-setup.sgml: same. - * C/usage-sync.sgml: same. - -2000-05-07 Dan Winship <danw@helixcode.com> - - * Camel-Classes: sync - -2000-04-16 Aaron Weber <aaron@helixcode.com> - - * C/evo_book_0.1.sgml: new file (doc sgml) - - * C/ : New directory for doc sgml & graphics - -2000-03-05 Christopher James Lahey <clahey@helixcode.com> - - * white-papers/widgets/e-table.sgml: Added Miguel to the author - list for ETable. - -2000-03-03 Christopher James Lahey <clahey@helixcode.com> - - * white-papers/widgets/, white-papers/widgets/e-table.sgml: New - doc for the ETable widget. - - * ChangeLog: Created a ChangeLog file for the docs file and - integrated the individual ChangeLogs. - -2000-03-01 Dan Winship <danw@helixcode.com> - - * ibex.sgml: Ibex white paper - -2000-02-29 Federico Mena Quintero <federico@helixcode.com> - - * calendar.sgml: Sections for the calendar user agent and the - calendar client library. - -2000-02-29 Dan Winship <danw@helixcode.com> - - * camel.sgml: Reorg a bit more, make the <PRE> section narrower, - add more references to graphics (the graphics themselves are - still in beta), add a section on CamelStream. - -2000-02-28 Federico Mena Quintero <federico@helixcode.com> - - * calendar.sgml: Section for the personal calendar server. - -2000-02-28 Dan Winship <danw@helixcode.com> - - * camel.sgml: add Bertrand to authors, edit his additions - -2000-02-28 bertrand <bertrand@helixcode.com> - - * camel.sgml: add a blurb about camel offering - uniform interface. needs style and grammar corrections. - Talk about virtual folders. - Talk about lightweight messages - Talk about IMAP. - -2000-02-28 Dan Winship <danw@helixcode.com> - - * camel.sgml: Beginnings of a Camel white paper - -2000-02-25 Federico Mena Quintero <federico@helixcode.com> - - * calendar.sgml: New file for the Evolution calendaring white paper. diff --git a/doc/Design b/doc/Design deleted file mode 100644 index 7b7cf6f821..0000000000 --- a/doc/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. - diff --git a/doc/Keybindings b/doc/Keybindings deleted file mode 100644 index f232802110..0000000000 --- a/doc/Keybindings +++ /dev/null @@ -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. - diff --git a/doc/Makefile.am b/doc/Makefile.am deleted file mode 100644 index 965492689a..0000000000 --- a/doc/Makefile.am +++ /dev/null @@ -1 +0,0 @@ -EXTRA_DIST = ChangeLog.pre-1-4 diff --git a/doc/NAMESPACE b/doc/NAMESPACE deleted file mode 100644 index 4ca7c454d1..0000000000 --- a/doc/NAMESPACE +++ /dev/null @@ -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 - diff --git a/doc/devel/.cvsignore b/doc/devel/.cvsignore deleted file mode 100644 index 81268d18cf..0000000000 --- a/doc/devel/.cvsignore +++ /dev/null @@ -1,5 +0,0 @@ -Makefile -Makefile.in -html -evolution-devel-guide.html -*.stamp diff --git a/doc/devel/ChangeLog b/doc/devel/ChangeLog deleted file mode 100644 index 0b137d8036..0000000000 --- a/doc/devel/ChangeLog +++ /dev/null @@ -1,57 +0,0 @@ -2004-11-18 Not Zed <NotZed@Ximian.com> - - * evolution-plugin-manual.xml: define load-on-startup parameter. - -2004-11-03 Not Zed <NotZed@Ximian.com> - - * evolution-plugin-manual.xml: added author section to eplugin - definition. - -2004-10-28 Not Zed <NotZed@Ximian.com> - - * evolution-plugin-manual.xml: setup for more auto-built stuff. - - * build-eplugin-manual.pl: auto-build more stuff. - -2004-10-12 Not Zed <NotZed@Ximian.com> - - * evolution-plugin-manual.xml: doc updates for new 'check' callback. - -2004-10-07 Not Zed <NotZed@Ximian.com> - - * evolution-plugin-manual.xml: some updates. - -2004-09-09 Not Zed <NotZed@Ximian.com> - - * evolution-plugin-manual.xml: updates. some not very readable, sigh. - - * images: Added e-popup-merge-[12].pic. - -2004-09-04 Not Zed <NotZed@Ximian.com> - - * images/Makefile: add a temporary makefile to build images from - source pic files. - - * evolution-plugin-manual.xml: updates/rearrangements. - -2004-09-01 Not Zed <NotZed@Ximian.com> - - * images/*: added some image files. - - * evolution-plugin-manual.xml: fix for some api changes. Updates. - -2004-08-25 Not Zed <NotZed@Ximian.com> - - * evolution-plugin-manual.xml: Added the working plugin manual - in-case i crash my bike going to work one day. - -2003-11-20 JP Rosevear <jpr@ximian.com> - - * Remove dead doc files. - -2003-09-11 Dan Winship <danw@ximian.com> - - * calendar/cal-client/Makefile.am (GTKDOC_LIBS): Use non-static - libraries. - - * calendar/cal-util/Makefile.am (GTKDOC_LIBS): Likewise diff --git a/doc/devel/ChangeLog.pre-1-4 b/doc/devel/ChangeLog.pre-1-4 deleted file mode 100644 index 4d90e1e515..0000000000 --- a/doc/devel/ChangeLog.pre-1-4 +++ /dev/null @@ -1,286 +0,0 @@ -2003-01-22 Ettore Perazzoli <ettore@ximian.com> - - * Makefile.am (HTML_DIR): Version using $(BASE_VERSION). - -2002-07-17 Peter Williams <peterw@ximian.com> - - * calendar/cal-util/Makefile.am (GTKDOC_LIBS): Because we're - using libtool as our LD, we can reference .la's and libtool - will DTRT for us. - - * calendar/cal-client/Makefile.am (GTKDOC_LIBS): Same here. - -2002-03-19 Dan Winship <danw@ximian.com> - - * calendar/cal-util/Makefile.am (GTKDOC_LIBS): Update for - libversit change. - - * calendar/cal-client/Makefile.am (GTKDOC_LIBS): Likewise - -2002-01-24 Ettore Perazzoli <ettore@ximian.com> - - * calendar/cal-client/Makefile.am: Use EVOLUTION_CALENDAR_CFLAGS - and EVOLUTION_CALENDAR_LIBS. - * calendar/cal-util/Makefile.am: Likewise. - -2001-12-18 JP Rosevear <jpr@ximian.com> - - * calendar/cal-client/Makefile.am: cal-client needs bonobo-conf - now - -2001-10-29 Federico Mena Quintero <federico@ximian.com> - - * calendar/alarm-generation.sgml: Updated docs for repeating - alarms. - -2001-07-31 Ettore Perazzoli <ettore@ximian.com> - - * Makefile.am (dist-hook): Remove the copying of the - index.sgml file which doesn't seem to be generated - anywhere anyway. - -2001-06-25 Peter Williams <peterw@ximian.com> - - * Makefile.am: ... and comment out more exec summary stuff. - - * reference.sgml: Here too. - -2001-06-25 Peter Williams <peterw@ximian.com> - - * calendar/cal-util/Makefile.am, - calendar/cal-client/Makefile.am: Fix make dist. - - * Makefile.am: clean up a bit. - -2001-06-21 JP Rosevear <jpr@ximian.com> - - * Makefile.am: disable executive summary build because it is no - longer built - -2001-06-21 JP Rosevear <jpr@ximian.com> - - * calendar/cal-client/Makefile.am: add new lib - -2001-06-21 Peter Williams <peterw@ximian.com> - - * Makefile.am: - calendar/cal-client/Makefile.am: - calendar/cal-util/Makefile.am: - importer/Makefile.am: - executive-summary/Makefile.am: Changed to used gtk-doc's - canonical Makefile.am (plus some tweaks because not every - dir builds html). - -2001-06-14 Damon Chaplin <damon@ximian.com> - - * executive-summary/.cvsignore: - * calendar/cal-util/.cvsignore: - * calendar/cal-client/.cvsignore: added *-undocumented.txt - -2001-05-24 Federico Mena Quintero <federico@ximian.com> - - * evolution-devel-guide.sgml: s/Helix Code/Ximian - -2001-05-15 Jeffrey Stedfast <fejj@ximian.com> - - * Removed some evolution-*-decl.txt files since these are - autogenerated by gtk-doc and don't belong in cvs anyway. - Should the tmpl/ dirs also be removed?? - - Updated: Readded them and updated the .cvsignore files - I guess - we do need them after all ;-) - -2001-04-25 Jon Trowbridge <trow@ximian.com> - - * Removed generated files from CVS, updated .cvsignore files - to include generated files. - -2001-04-23 Ettore Perazzoli <ettore@ximian.com> - - * executive-summary/Makefile.am (scan) [ENABLE_GTK_DOC]: Kludge - builddir != srcdir behavior by symlinking the $(DOC_MODULE).types - file into the builddir. - * calendar/cal-client/Makefile.am (scan) [ENABLE_GTK_DOC]: - Likewise. - * calendar/cal-util/Makefile.am (scan) [ENABLE_GTK_DOC]: Likewise. - -2001-04-23 Ettore Perazzoli <ettore@ximian.com> - - * evolution-devel-guide.sgml: Disable the importer references here - too. - - * Makefile.am: Remove the importer stuff for now. - -2001-04-20 Damon Chaplin <damon@ximian.com> - - * importer/evolution-shell-importer.types: changed path to the - importer header files, since we've had reports that they aren't being - found (though it worked OK for me). - -2001-04-17 Ettore Perazzoli <ettore@ximian.com> - - * calendar/cal-client/Makefile.am (install-data-local): Install - the $(DOC_DIR_INSTALL_FILES) from the srcdir. - * calendar/cal-util/Makefile.am (install-data-local): Likewise. - * importer/Makefile.am (install-data-local): Likewise. - * executive-summary/Makefile.am (install-data-local): Likewise. - -2001-01-26 John R. Sheets <dusk@ravendusk.org> - - * importer/Makefile.am: Change (nonexistant) importer.sgml - references to evolution-importer.sgml to fix dependency problem. - -2001-01-17 Iain Holmes <iain@ximian.com> - - * Makefile.am (local_entities): Added the importer stuff. - - * evolution-devel-guide.sgml: Added entities for the importer documents. - - * reference.sgml: Added the public and private APIs for the importer. - - * importer/*: New directory containing all the documenation for the - importer. - -2001-01-17 Federico Mena Quintero <federico@ximian.com> - - * evolution-devel-guide.sgml: Ximianified. - - * calendar/evolution-calendar.sgml: Ditto. - - * calendar/cal-util/evolution-cal-util-sections.txt: Updated. - - * calendar/cal-client/evolution-cal-client-sections.txt: Updated. - -2001-01-10 Federico Mena Quintero <federico@helixcode.com> - - * Makefile.am: Make it work when gtk-doc is not installed. - - * calendar/cal-client/Makefile.am: Likewise. - - * calendar/cal-util/Makefile.am: Likewise. - -2000-12-19 Federico Mena Quintero <federico@helixcode.com> - - Added proper dependency lists to the gtk-doc mess. - - * calendar/cal-client/Makefile.am (TARGET_DIR): Removed unused - variable. - (SOURCE_FILES): New variable with the list of source files we - depend on. - (IGNORED_SOURCE_HEADERS): New variable with the headers we ignore - for the gtkdoc-scan phase. - (scan_generated): - (tmpl_dependencies): - (tmpl_sources): - (tmpl_generated); - (sgml_dependencies): - (sgml_generated): Lists of stuff that is generated and that other - stuff depends on. - (all): Added the $(sgml_generated) as the final target. - (install-data-local): Added an installation hook; gtk-doc seems to - want some of its generated files to be installed. - - * calendar/cal-client/evolution-cal-client-sections.txt: Updated. - - * calendar/cal-util/Makefile.am: Made the same changes as for - calendar/cal-client/Makefile.am. - - * calendar/cal-util/evolution-cal-util-sections.txt: Updated. - - * Makefile.am (local_entities): Added alarm-generation.sgml. - (all): Made the main target be the html/index.html. - -2000-12-18 Federico Mena Quintero <federico@helixcode.com> - - * calendar/alarm-generation.sgml: New file with a description of - the algorithm used to generate alarm instances. - - * evolution-devel-guide.sgml: Added an entity for the above - chapter. - - * calendar/evolution-calendar.sgml: Reference the entity here. - - * calendar/Makefile.am (EXTRA_DIST): Added alarm-generation.sgml. - -2000-12-13 Larry Ewing <lewing@helixcode.com> - - * calendar/Makefile.am (EXTRA_DIST): make it public-reference.sgml - not referenc.sgml here. - -2000-11-29 Federico Mena Quintero <federico@helixcode.com> - - * calendar/architecture.sgml: Finished the calendar architecture - chapter. - -2000-11-29 Federico Mena Quintero <federico@helixcode.com> - - * evolution-devel-guide.sgml: Added an id for the API reference <part>. - Added the FDL <legalnotice>. - Added the preface and toplevel reference entities. - Added entities for Evolution, Wombat, and Camel. - Added an appendix for the GNU FDL. - - * preface.sgml: New file with the introduction to the Evolution - Developer's Guide. - - * reference.sgml: Split the toplevel reference part into its own - file. - - * fdl.sgml: Added the GNU Free Documentation License. - - * calendar/evolution-calendar.sgml: Added an id for the <part>. - - * calendar/public-reference.sgml: Added an id for the <reference>. - Moved this file over from calendar/reference.sgml. - - * Makefile.am (local_entities): Added a list of the SGML files - that define entities for inclusion in the toplevel document. This - way we can track documentation file dependencies down to all - levels. - (html/index.html): Made the toplevel document depend on - $(local_entities). Also, removed the "html" target and put its - contents directly here; this way we avoid having .PHONY targets. - (EXTRA_DIST): Removed the evolution_devel_guideDATA; it made no - sense. - (content_files): Added preface.sgml and reference.sgml. - -2000-09-15 Federico Mena Quintero <federico@helixcode.com> - - * evolution-devel-guide.sgml: Made the toplevel <book> id be - "index". - -2000-08-14 Federico Mena Quintero <federico@helixcode.com> - - * calendar/cal-util/*: Integrated the cal-util library into the - documentation framework. - - * calendar/Makefile.am (SUBDIRS): Added the cal-util directory. - - * evolution-devel-guide.sgml: Added entities for the cal-util stuff. - Added entity for libical. - - * calendar/reference.sgml: Added the cal-util reference entries. - - * calendar/cal-client/evolution-cal-client-sections.txt: Updated - for new API. - -2000-08-09 Peter Williams <peterw@helixcode.com> - - * Makefile.am (maintainer-clean-local): Don't depend - on 'clean'; this messes up maintainer-clean. - -2000-07-17 Federico Mena Quintero <federico@helixcode.com> - - * calendar/cal-client/tmpl/cal-client.sgml: Populated. - - * evolution-devel-guide.sgml: New <book> toplevel for the - Evolution Developer's Guide. - - * calendar/evolution-calendar.sgml: New <part> for the calendar - developer's documentation. - - * calendar/architecture.sgml: New <chapter> for the calendar - architecture. - - * calendar/reference.sgml: New <reference> for the calendar API - reference. diff --git a/doc/devel/Makefile.am b/doc/devel/Makefile.am deleted file mode 100644 index 7940af73f5..0000000000 --- a/doc/devel/Makefile.am +++ /dev/null @@ -1,179 +0,0 @@ -## Process this file with automake to produce Makefile.in - -SUBDIRS = calendar - -# The name of the module, e.g. 'glib'. -DOC_MODULE=evolution-devel-guide - -# The top-level SGML file. Change it if you want. -DOC_MAIN_SGML_FILE=evolution-devel-guide.sgml - -# The directory containing the source code. Relative to $(srcdir). -# gtk-doc will search all .c & .h files beneath here for inline comments -# documenting functions and macros. -#DOC_SOURCE_DIR= - -# Extra options to supply to gtkdoc-scan. -#SCAN_OPTIONS= - -# Extra options to supply to gtkdoc-mkdb. -#MKDB_OPTIONS= - -# Extra options to supply to gtkdoc-fixref. -#FIXXREF_OPTIONS= - -# Used for dependencies. -#HFILE_GLOB= -#CFILE_GLOB= - -# Header files to ignore when scanning. -#IGNORE_HFILES= - -# Images to copy into HTML directory. -HTML_IMAGES = - - -# Add your module's hand-written and auto-generated files here; these -# are used for dependency tracking. - -local_entities = \ - calendar/alarm-generation.sgml \ - calendar/architecture.sgml \ - calendar/evolution-calendar.sgml \ - calendar/public-reference.sgml \ - \ - calendar/cal-client/sgml/cal-client.sgml \ - \ - calendar/cal-util/sgml/cal-component.sgml \ - calendar/cal-util/sgml/cal-recur.sgml \ - calendar/cal-util/sgml/cal-util.sgml \ - calendar/cal-util/sgml/timeutil.sgml - -# executive-summary/sgml/executive-summary-component.sgml \ -# executive-summary/sgml/executive-summary-component-factory.sgml \ -# executive-summary/sgml/executive-summary-component-factory-client.sgml \ -# executive-summary/sgml/executive-summary-html-view.sgml - -# importer/sgml/evolution-importer.sgml \ -# importer/sgml/evolution-importer-client.sgml - -installed_content_files = \ - fdl.sgml \ - preface.sgml \ - reference.sgml - -# Extra SGML files that are included by $(DOC_MAIN_SGML_FILE). -content_files = \ - $(installed_content_files) \ - $(local_entities) - -# Other files to distribute. -extra_files = - -# CFLAGS and LDFLAGS for compiling scan program. Only needed if your app/lib -# contains GtkObjects/GObjects and you want to document signals and properties. -#GTKDOC_CFLAGS = -#GTKDOC_LIBS = -# -#GTKDOC_CC=$(LIBTOOL) --mode=compile $(CC) -#GTKDOC_LD=$(LIBTOOL) --mode=link $(CC) - -# If you need to override some of the declarations, place them in this file -# and uncomment this line. -#DOC_OVERRIDES = $(DOC_MODULE)-overrides.txt - -HTML_DIR = $(datadir)/gnome/html/evolution-$(BASE_VERSION) - -########################################################################### -# Everything below here is generic and you shouldn't need to change it. -########################################################################### - -TARGET_DIR=$(HTML_DIR)/$(DOC_MODULE) - -EXTRA_DIST = \ - $(extra_files) \ - $(installed_content_files) \ - $(HTML_IMAGES) \ - $(DOC_MAIN_SGML_FILE) \ - ChangeLog.pre-1-4 - -# $(DOC_MODULE).types \ -# $(DOC_MODULE)-sections.txt \ -# $(DOC_OVERRIDES) - -DOC_STAMPS=scan-build.stamp tmpl-build.stamp sgml-build.stamp html-build.stamp \ - $(srcdir)/tmpl.stamp $(srcdir)/sgml.stamp $(srcdir)/html.stamp - -#SCANOBJ_FILES = \ -# $(DOC_MODULE).args \ -# $(DOC_MODULE).hierarchy \ -# $(DOC_MODULE).signals - -if ENABLE_GTK_DOC -all-local: html-build.stamp - -#### html #### - -html-build.stamp: $(DOC_MAIN_SGML_FILE) $(content_files) #sgml.stamp - @echo '*** Building HTML ***' - test -d $(srcdir)/html || mkdir $(srcdir)/html - cd $(srcdir)/html && gtkdoc-mkhtml $(DOC_MODULE) ../$(DOC_MAIN_SGML_FILE) - test "x$(HTML_IMAGES)" = "x" || ( cd $(srcdir) && cp $(HTML_IMAGES) html ) - @echo '-- Fixing Crossreferences' - cd $(srcdir) && gtkdoc-fixxref --module-dir=html --html-dir=$(HTML_DIR) $(FIXXREF_OPTIONS) - touch html-build.stamp -endif - -############## - -clean-local: - rm -f *~ *.bak *-unused.txt $(DOC_STAMPS) # $(SCANOBJ_FILES) - -maintainer-clean-local: clean - cd $(srcdir) && rm -rf sgml html $(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt - -install-data-local: - $(mkinstalldirs) $(DESTDIR)$(TARGET_DIR) - (installfiles=`echo $(srcdir)/html/*.html`; \ - if test "$$installfiles" = '$(srcdir)/html/*.html'; \ - then echo '-- Nothing to install' ; \ - else \ - for i in $$installfiles; do \ - echo '-- Installing '$$i ; \ - $(INSTALL_DATA) $$i $(DESTDIR)$(TARGET_DIR); \ - done; \ - fi) - -# echo '-- Installing $(srcdir)/html/index.sgml' ; \ -# $(INSTALL_DATA) $(srcdir)/html/index.sgml $(DESTDIR)$(TARGET_DIR); \ - -# -# Require gtk-doc when making dist -# -if ENABLE_GTK_DOC -dist-check-gtkdoc: -else -dist-check-gtkdoc: - @echo "*** gtk-doc must be installed and enabled in order to make dist" - @false -endif - -dist-hook: dist-check-gtkdoc dist-hook-local - mkdir $(distdir)/html - files=`echo $(srcdir)/html/*.html` ; \ - test '$(srcdir)/html/*.html' = "$$files" \ - || cp $$files $(distdir)/html - files=`echo $(srcdir)/html/*.css` ; \ - test '$(srcdir)/html/*.css' = "$$files" \ - || cp $$files $(distdir)/html - images=$(HTML_IMAGES) ; \ - for i in $$images ; do \ - cp $(srcdir)/$$i $(distdir)/html ; \ - done - -# mkdir $(distdir)/tmpl -# mkdir $(distdir)/sgml -# -cp $(srcdir)/sgml/*.sgml $(distdir)/sgml -# -cp $(srcdir)/tmpl/*.sgml $(distdir)/tmpl - -.PHONY : dist-hook-local diff --git a/doc/devel/build-eplugin-manual.pl b/doc/devel/build-eplugin-manual.pl deleted file mode 100755 index 8cb951a516..0000000000 --- a/doc/devel/build-eplugin-manual.pl +++ /dev/null @@ -1,263 +0,0 @@ -#!/usr/bin/perl - -# -# API reference -# - -%byref = ( 'e-popup.xml' => - { 'files' => [ 'e-popup.h', 'e-popup.c' ], - 'module' => 'e-util' }, - - 'e-menu.xml' => - { 'files' => [ 'e-menu.h', 'e-menu.c' ], - 'module' => 'e-util' }, - - 'e-event.xml' => - { 'files' => [ 'e-event.h', 'e-event.c' ], - 'module' => 'e-util' }, - - 'e-config.xml' => - { 'files' => [ 'e-config.h', 'e-config.c' ], - 'module' => 'e-util' }, - - 'e-plugin.xml' => - { 'files' => [ 'e-plugin.h', 'e-plugin.c' ], - 'module' => 'e-util' }, - - 'em-popup.xml' => - { 'files' => [ 'em-popup.h', 'em-popup.c' ], - 'module' => 'mail' }, - - 'em-format.xml' => - { 'files' => [ 'em-format-hook.h' , 'em-format-hook.c', - 'em-format.h', 'em-format.c', - 'em-format-html.h', 'em-format-html.c' ], - 'module' => 'mail' }, - ); - -foreach $out (keys %byref) { - print "file $out\n"; - %data = %{$byref{$out}}; - @files = @{$data{'files'}}; - $module = $data{'module'}; - $files = ""; - foreach $file (@files) { - $files .= " ../../".$module."/".$file; - } - system("kernel-doc -docbook $files > $out"); -} - -# -# Event reference -# - -# %events = ( 'em-events.xml' => -# { 'files' => [ 'em-folder-view.c', 'em-composer-utils.c', 'mail-folder-cache.c' ], -# 'module' => 'mail' }, -# ); - -# foreach $out (keys %events) { -# print "generating events doc $out\n"; -# %data = %{$events{$out}}; -# @files = @{$data{'files'}}; -# $module = $data{'module'}; -# open OUT,">$out"; -# foreach $file (@files) { -# open IN,"<../../$module/$file"; -# while (<IN>) { -# if (m/\@Event: (.*)/) { -# $title = $1; -# $name = $1; -# $target = ""; -# while (<IN>) { -# if (m/\@Title: (.*)/) { -# $title = $1; -# } elsif (m/\@Target: (.*)/) { -# $target = $1; -# } elsif (m/\* (.*)/) { -# $desc.= $1."\n"; -# } -# last if (m/\*\//); -# } -# if ($target eq "") { -# print "Warning: No target defined for event $name ($title)\n"; -# } -# print OUT <<END; -# <sect2> -# <title>$title</title> -# <informaltable> -# <tgroup cols="2"> -# <colspec colnum="1" colname="field" colwidth="1*"/> -# <colspec colnum="2" colname="value" colwidth="4*"/> -# <tbody valign="top"> -# <row> -# <entry>Name</entry> -# <entry><constant>$name</constant></entry> -# </row> -# <row> -# <entry>Target</entry> -# <entry> -# <link -# linkend="$module-hooks-event-$target">$target</link> -# </entry> -# </row> -# <row> -# <entry>Description</entry> -# <entry> -# <simpara> -# $desc -# </simpara> -# </entry> -# </row> -# </tbody> -# </tgroup> -# </informaltable> -# </sect2> -# END -# } -# } -# close IN; -# } -# close OUT; -# } - -# -# Generic table builder, still experimental. -# - -sub buildxml { - my $type = $_[0]; - my $out = $_[1]; - my %data = %{$_[2]}; - my @files, $module; - my $line; - - print "generating doc $out for $type\n"; - @files = @{$data{'files'}}; - $module = $data{'module'}; - open OUT,">$out"; - foreach $file (@files) { - my $line = 0; - - open IN,"<../../$module/$file" || die ("Cannot open \"$module/$file\""); - while (<IN>) { - if (m/\/\*\* \@$type: (.*)/) { - my $key = ""; - my $val = ""; - my $desc = 0; - my $title = $1; - my %blob = { }; - my @blobs = (); - - while (<IN>) { - $line++; - if (m/\@(.*): (.*)/) { - if ($val ne "") { - $blob{$key} = $val; - } - $key = $1; - $val = $2; - push @blobs, $key; - } elsif (m/\* (.+)/) { - $val .= $1."\n"; - } else { - if ($desc == 0) { - if ($val ne "") { - $blob{$key} = $val; - } - $val = ""; - $key = ""; - } else { - $val .= "\n"; - } - if (m/\*\s*$/) { - $desc = 1; - } - } - last if (m/\*\//); - } - print OUT<<END; - <sect2> - <title>$title</title> -END - if ($val ne "") { - $val =~ s/[\n]+$//gos; - $val =~ s/\n\n/\<\/simpara\>\n\<simpara\>/g; - print OUT "<simpara>$val</simpara>\n"; - } - print OUT <<END; - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> -END - - foreach $key (@blobs) { - print OUT <<END; - <row> - <entry>$key</entry> - <entry>$blob{$key}</entry> - </row> -END -} - print OUT <<END; - <row> - <entry>Defined</entry> - <entry>$module/$file:$line</entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect2> -END - } - $line++; - } - close IN; - } - close OUT; -} - - -%hooks = ( 'es-hooks.xml' => - { 'type' => 'HookClass', - 'files' => [ 'es-menu.c', 'es-event.c' ], - 'module' => 'shell' }, - 'es-menus.xml' => - { 'type' => 'HookPoint', - 'files' => [ 'e-shell-window.c' ], - 'module' => 'shell' }, - 'es-events.xml' => - { 'type' => 'Event', - 'files' => [ 'e-shell.c' ], - 'module' => 'shell' }, - 'em-events.xml' => - { 'type' => 'Event', - 'files' => [ 'em-folder-view.c', 'em-composer-utils.c', 'mail-folder-cache.c' ], - 'module' => 'mail' }, - 'em-popups.xml' => - { 'type' => 'HookPoint-EMPopup', - 'files' => [ 'em-folder-tree.c', 'em-folder-view.c', 'em-format-html-display.c', '../composer/e-msg-composer-attachment-bar.c' ], - 'module' => 'mail' }, - 'ecal-popups.xml' => - { 'type' => 'HookPoint-ECalPopup', - 'files' => [ 'gui/e-calendar-view.c', 'gui/calendar-component.c', 'gui/e-calendar-view.c', 'gui/tasks-component.c' ], - 'module' => 'calendar' }, - 'em-configs.xml' => - { 'type' => 'HookPoint-EMConfig', - 'files' => [ 'em-mailer-prefs.c', 'em-account-editor.c', 'em-folder-properties.c', 'em-composer-prefs.c' ], - 'module' => 'mail' }, - 'em-menus.xml' => - { 'type' => 'HookPoint-EMMenu', - 'files' => [ 'em-folder-browser.c', 'em-message-browser.c' ], - 'module' => 'mail' }, - ); - -foreach $out (keys %hooks) { - %data = %{$hooks{$out}}; - - &buildxml($data{'type'}, $out, \%data); -} - - diff --git a/doc/devel/evolution-devel-guide.sgml b/doc/devel/evolution-devel-guide.sgml deleted file mode 100644 index c089c5b885..0000000000 --- a/doc/devel/evolution-devel-guide.sgml +++ /dev/null @@ -1,98 +0,0 @@ -<!DOCTYPE book PUBLIC "-//Davenport//DTD DocBook V3.0//EN"[ -<!ENTITY preface SYSTEM "preface.sgml"> -<!ENTITY evolution-reference SYSTEM "reference.sgml"> -<!ENTITY FDL SYSTEM "fdl.sgml"> - -<!ENTITY evolution-calendar SYSTEM "calendar/evolution-calendar.sgml"> -<!ENTITY calendar-architecture SYSTEM "calendar/architecture.sgml"> -<!ENTITY calendar-alarm-generation SYSTEM "calendar/alarm-generation.sgml"> -<!ENTITY calendar-public-reference SYSTEM "calendar/public-reference.sgml"> -<!ENTITY CalClient SYSTEM "calendar/cal-client/sgml/cal-client.sgml"> -<!ENTITY CalComponent SYSTEM "calendar/cal-util/sgml/cal-component.sgml"> -<!ENTITY cal-recur SYSTEM "calendar/cal-util/sgml/cal-recur.sgml"> -<!ENTITY cal-util SYSTEM "calendar/cal-util/sgml/cal-util.sgml"> -<!ENTITY timeutil SYSTEM "calendar/cal-util/sgml/timeutil.sgml"> - -<!ENTITY evolution-services-public-reference SYSTEM "executive-summary/public-reference.sgml"> -<!ENTITY evolution-services-private-reference SYSTEM "executive-summary/private-reference.sgml"> -<!ENTITY ExecutiveSummaryComponent SYSTEM "executive-summary/sgml/executive-summary-component.sgml"> -<!ENTITY ExecutiveSummaryComponentFactory SYSTEM "executive-summary/sgml/executive-summary-component-factory.sgml"> -<!ENTITY ExecutiveSummaryComponentFactoryClient SYSTEM "executive-summary/sgml/executive-summary-component-factory-client.sgml"> -<!ENTITY ExecutiveSummaryHtmlView SYSTEM "executive-summary/sgml/executive-summary-html-view.sgml"> - -<!ENTITY Evolution "<application>Evolution</application>"> -<!ENTITY Wombat "<application>Wombat</application>"> -<!ENTITY Camel "<application>Camel</application>"> -<!ENTITY PCS "<acronym>PCS</acronym>"> -<!ENTITY libical "<application>libical</application>"> -<!ENTITY Executive-Summary "<application>Executive Summary</application>"> -]> - -<!-- ENTITY importer-public-reference SYSTEM "importer/public-reference.sgml" --> -<!-- ENTITY importer-private-reference SYSTEM "importer/private-reference.sgml" --> -<!-- ENTITY EvolutionImporter SYSTEM "importer/sgml/evolution-importer.sgml" --> -<!-- ENTITY EvolutionImporterClient SYSTEM "importer/sgml/evolution-importer-client.sgml" --> -<!-- ENTITY EvolutionImporterListener SYSTEM "importer/sgml/evolution-importer-listener.sgml" --> - - -<book id="index"> - <bookinfo> - <title>&Evolution; Developer's Guide</title> - - <authorgroup> - <corpauthor> - Ximian, Inc. - </corpauthor> - </authorgroup> - - <copyright> - <year>2001</year> - <holder>Ximian, Inc.</holder> - </copyright> - - <copyright> - <year>2001</year> - <holder>Ximian, Inc.</holder> - </copyright> - - <legalnotice id="legalnotice"> - <para> - Permission is granted to copy, distribute and/or modify this - document under the terms of the <ulink type="help" - url="gnome-help:fdl"><citetitle>GNU Free Documentation - License</citetitle></ulink>, Version 1.1 or any later version - published by the Free Software Foundation with no Invariant - Sections, no Front-Cover Texts, and no Back-Cover Texts. You - may obtain a copy of the <citetitle>GNU Free Documentation - License</citetitle> from the Free Software Foundation by - visiting <ulink type="http" url="http://www.fsf.org">their Web - site</ulink> or by writing to: Free Software Foundation, Inc., - 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. - </para> - - <para> - Many of the names used by companies to distinguish their - products and services are claimed as trademarks. Where those - names appear in any GNOME documentation, and those trademarks - are made aware to the members of the GNOME Documentation - Project, the names have been printed in caps or initial caps. - </para> - </legalnotice> - </bookinfo> - - <!-- Introduction --> - - &preface; - - <!-- DocBook parts for each individual component --> - - &evolution-calendar; - - <!-- API Reference part --> - - &evolution-reference; - - <!-- Appendices --> - - &FDL; -</book> diff --git a/doc/devel/evolution-plugin-manual.xml b/doc/devel/evolution-plugin-manual.xml deleted file mode 100644 index 2feb047482..0000000000 --- a/doc/devel/evolution-plugin-manual.xml +++ /dev/null @@ -1,2803 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ - -<!ENTITY Evolution "<application>Evolution</application>"> -<!ENTITY GNOME "<application>GNOME</application>"> -<!ENTITY eclipse "<application>Eclipse</application>"> -<!ENTITY Camel "<application>Camel</application>"> -<!ENTITY EPlugin "<application>EPlugin</application>"> -<!ENTITY e-popup-reference SYSTEM "e-popup.xml"> -<!ENTITY e-menu-reference SYSTEM "e-menu.xml"> -<!ENTITY e-config-reference SYSTEM "e-config.xml"> -<!ENTITY e-event-reference SYSTEM "e-event.xml"> -<!ENTITY e-plugin-reference SYSTEM "e-plugin.xml"> - -<!ENTITY em-popup-reference SYSTEM "em-popup.xml"> -<!ENTITY em-format-reference SYSTEM "em-format.xml"> - -<!ENTITY em-popups SYSTEM "em-popups.xml"> -<!ENTITY em-menus SYSTEM "em-menus.xml"> -<!ENTITY em-configs SYSTEM "em-configs.xml"> -<!ENTITY em-events SYSTEM "em-events.xml"> - -<!ENTITY ecal-popups SYSTEM "ecal-popups.xml"> - -<!ENTITY es-events SYSTEM "es-events.xml"> -<!ENTITY es-menus SYSTEM "es-menus.xml"> - -]> -<?xml-stylesheet href="sdocbook.css" type="text/css"?> - -<book lang="en"> - <!-- DocBook file was created by LyX 1.3 - See http://www.lyx.org/ for more information --> - <bookinfo> - <title> - &Evolution; Plugin Development Manual - </title> - - <authorgroup> - <corpauthor> - Novell, Inc. - </corpauthor> - <author> - <firstname>Michael</firstname><surname>Zucchi</surname> - </author> - </authorgroup> - - <copyright> - <year>2004</year> - <holder>Novell, Inc.</holder> - </copyright> - - </bookinfo> - - <preface id="preface"> - <title>Preface</title> - - <para> - This document is work-in-progress. Its structure and design is still as - fluid as the underlying strucutre and design of some parts of EPlugin. - There's no guarantee it will be updated at regular intervals, - particularly this version. - </para> - <para> - The API documentation is currently generated using the Linux kernel-doc - script. The stylesheets used to generate the HTML you're seeing seems to - have bugs which duplicates some sections. It is also ugly and difficult - to navigate. - </para> - - <sect1> - <title>Conventions</title> - <para> - The following conventions are used in the manual ... (insert details - here). - </para> - <sect2> - <title>XML Annotation</title> - <para> - XML definitions are annotated with BNF-style markers to indicate - alternative (|), multiples (* or +), and optional (?) items. If no - annotation is present then the item must be present once. - </para> - <variablelist> - <varlistentry> - <!-- is symbol the right one here? --> - <term><symbol>|</symbol></term> - <listitem> - <simpara>Indicates an alternative option. Only one of the items - separated by <symbol>|</symbol> is to be chosen. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><symbol>*</symbol></term> - <listitem> - <simpara>Following an item, <symbol>*</symbol> indicates the item - may occur any number of times, including no times (0 or more - multiple). - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><symbol>+</symbol></term> - <listitem> - <simpara>Following an item, <symbol>+</symbol> indicates the item - must occur at least once, but may occur more than ones (1 or - more multiple). - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><symbol>?</symbol></term> - <listitem> - <simpara>Following an item, <symbol>?</symbol> indicates the item - may occur at most once, if present (0 or 1 times). - </simpara> - </listitem> - </varlistentry> - </variablelist> - </sect2> - </sect1> - - </preface> - - <part id="informational"> - <title> - EPlugin - </title> - <chapter> - <title> - Introduction - </title> - <para> - This book aims to be a comprehensive technical manual for the - development of plugins for &Evolution;, a personal information manager - for &GNOME;. - </para> - <para> - Up-to, and including, &Evolution; version 2.0, &Evolution; contained - limited extensibility interfaces. There were only two ways to extend - &Evolution;; by implementing a new top-level component, or by - implementing a &Camel; provider. When implementing a top-level component, - there was still little integration, and in effect it was merely a more - complex way of writing a separate &GNOME; application. &Camel; providers - were only designed to be e-mail storage backends, so were of limited - use for general extensibility. Despite this, both mechanisms were used - for example for the Exchange Connector, although the system made the - integration clumsy and difficult. - </para> - <para> - This lack of extensibility has severaly stifled external developer - contributions by forcing any extensions to be considered as core - features. &Evolution; being a commercial product, it has tight usability - and quality requirements that limits the ability to experiment with - the core feature set in this way. As a result, very few lines of code - or new features have been implemented by external contributors. - </para> - <para> - One of the major goals for the 2.2 release was to implement an - extensibility system, given the working name of EPlugin, which must - provide a frame-work for both providing extensibility hooks, and for - extending the functionality of &Evolution;. - </para> - <sect1> - <title> - Plugin System - </title> - <para> - Any plugin system will generally have a number of goals: - </para> - <itemizedlist> - <listitem> - <simpara> - Provide a language independent invocation mechanism - </simpara> - </listitem> - <listitem> - <simpara> - Allow extension of parts of the user interface and processing elements - </simpara> - </listitem> - <listitem> - <simpara> - Require minimal extra or foreign code to implement in the core application - </simpara> - </listitem> - <listitem> - <simpara> - Require minimal interface code to implement the extensions - </simpara> - </listitem> - <listitem> - <simpara> - Not to impact performance or increase resource usage unduly - </simpara> - </listitem> - <listitem> - <simpara> - Versioning - </simpara> - </listitem> - <listitem> - <simpara> - Be able to be extended itself fairly easily. - </simpara> - </listitem> - </itemizedlist> - <para> - EPlugin manages to fulfill these goals in most cases. EPlugin isn't a - single object or interface in itself, although there is an object - titled EPlugin, it is a synergistic - <footnote><simpara>I've always wanted to use - <emphasis>synergistic</emphasis> in a sentence since - I read it on the back of the Commodore 64 Users - Guide.</simpara></footnote> - collection of integrated and - continually evolving objects which work together to achieve these - goals (and that will definitly be the end of the MarketSpeak). It - consists of a loader to invoke extension callbacks, hooks to resolve - these callbacks, targets to identify context, and managers which are - used by the core code to provide functionality and merging points for - the extensions. - </para> - <para> - EPlugin's design was inspired and influenced by the &eclipse; - project. It aims at a lower target however, so it was able more easily - implemented in a practical time-frame. - </para> - <para> - &EPlugin; was chosen as an approach to the problem of adding - scriptability to &Evolution;. Instead of just linking to Perl, or - Python, or even Mono by itself an approach was taken which focuses on - the application end of the system. So instead of making every part - of the application export its functionality and have to deal with - whatever script engine is present, EPlugin addresses the hooking part - of the equation in a language-independent manner. It also attemps to - do it in a way which doesn't impact on the application development - either. - </para> - <para> - The EPlugin world is awash with its own language. The next few - sections will introduce the basic plugin nomenclature and high-level - view of this world. - </para> - - </sect1> - - <sect1> - <title> - Loaders - </title> - <para> - The core of EPlugin is a light-weight object loader and callback - invocation system. Because of the varied calling conventions of - different languages, and to reduce the overhead of the plugin system - itself, all callbacks only receive and return a single argument. By - using structures to pass complex arguments, native C plugins require - no extra overhead, and marshalling details are moved into the plugin - implementation itself where required. It also simplifies memory - management issues significantly. For example, the C plugin handler - merely loads a shared library using GModule, and resolves a symbol by - name; and is so all of 50 lines of code, total. The loaders are the - only modules which need to interace with non-native code or - conventions. - </para> - <para> - The other task of the plugin core is to load XML definitions of the - plugins. Extension hooks are registered with the plugin core before - the plugins are scanned, and are automatically instantiated to load - each definition appropriately as they are encountered. - </para> - <para> - At each layer, a level of indirection is used so that new loaders and - new hooks can be added transparently, and extend the plugin - definition freely with any information they require. - </para> - </sect1> - - <sect1> - <title> - Hooks - </title> - <para> - The hooks - <footnote> - <para>A hook is something you can hang your stuff on.</para> - </footnote> - which are registered with the loader provide meta-data for - the management implementation layer for extending it at - run-time. Their primary - functions are to load the detail of the XML plugin definition, map it - to the implementation, and marshal the implementation callbacks to - the common plugin interface. How they do this depends on the - implementation itself, and ranges from registering factory methods to - simply adding the items directly. - </para> - <para> - In most cases the physical object need not be loaded until the - callback is invoked, since the plugin definitions provide enough - contextual information to build the interface or determine when they - need to be invoked. - </para> - </sect1> - - <sect1> - <title> - Managers - </title> - <para> - Managers - <footnote> - <para> - Unlike real managers, these are the ones that do the heavy lifting. - </para> - </footnote> - provide tools for the core code to extend itself at specific - points, and in many cases are the objects used directly in the code - to implement core features. In other cases they simply provide the - hooks with an entry point into &Evolution;. For example, for the main - menu hook, the manager is a thin layer to BonoboUI. On the other - hand, EPopup is a complete implementation of a popup menu management - system which was already used in &Evolution; 2.0. Some managers are - one-off objects used as constructors for other objects, others are - view-dependent, and some are static objects, such as the Event - routers. - </para> - </sect1> - - <sect1> - <title> - Items - </title> - <para> - Each manager uses a number of items to describe the object they - control or create. The items are added to each manager instance from - the plugins or from core code. The items from all of these sources - are then merged together when required and processed accordingly. For - example, menu items are merged into a tree of GtkMenus. Events on the - other hand are simply ordered and then invoked in the order of their - priority. Items are part of the manager implementation, and in - &EPlugin; they are all extensible objects too, which the hooks use to - perform mapping to the plugin. Items may be extended by code hooking - into the implementation, either the plugin hooks, or the core code. - </para> - </sect1> - - <sect1> - <title> - Targets - </title> - <para> - Targets - <footnote><para>Think of a target as the target of - interest.</para></footnote> - are view or component specific context objects. They contain - enough information to be used as stand-alone contexts to implement - callbacks for both core functions and plugin hooks. For example for - the mail view, a select target contains a folder and a list of - selected messages. An attachment (part) target contains the - &Camel; representation of the part and the mime-type for - that part. Targets are part of the manager implementation and are - extended by subclassing the manager. - </para> - </sect1> - </chapter> - - <chapter id="plugin-loaders"> - <title> - Plugin Loaders - </title> - <para> - Plugin loaders implement a hool to a new language, or loading system in the - plugin system. The actual binding of new languages to the plugin system or - other parst of &Evolution;s api's are beyond the scope of this - document, some languages make this easier than others. - </para> - <sect1 id="plugin-loaders-base"> - <title> - Base Plugin - </title> - <para> - The <link linkend="API-struct--EPlugin">EPlugin base class</link> - is an abstract class which provides the basic services for plugin - implementations. The main services are: - <itemizedlist> - <listitem><simpara>Resolve plugin type and instantiate an EPlugin - object to represent and manage it.</simpara></listitem> - <listitem><simpara>Load the base structure of the XML plugin - definition files.</simpara></listitem> - <listitem><simpara>Resolve plugin hook types and instantiate a - EPluginHook to represent and manage it.</simpara></listitem> - <listitem><simpara>Provide a simple, language-independent api for - invoking plugin callbacks</simpara></listitem> - <listitem><simpara>Provide I18N context for plugins.</simpara></listitem> - <listitem><simpara>Some simple static helper methods to simplify each - implementing class.</simpara></listitem> - </itemizedlist> - See the <xref linkend="REF-EPlugin"/> for - these details. - </para> - - <sect2 id="plugin-loaders-definition"> - <title>Definition of a Plugin</title> - <para> - The base plugin XML definition. Subclasses of EPlugin extend this - basic structure with additional parameters or elements as they - require. - </para> - <para> - Note that there may be any number of <sgmltag>e-plugin</sgmltag> - elements in a given plugin file, this may be used to simplify - distribution of plugin packages. - </para> - <programlisting> - <![CDATA[ -<?xml version="1.0"> -<e-plugin-list> - <e-plugin - id="unique id" - type="loader type" - domain="translation domain" ? - name="plugin name" - ...> - <description>long description</description> ? - <author name="real name"? email="email addr"?/> * - <hook - class="hook class" - ...> - ... - </hook> + - </e-plugin> + -</e-plugin-list>]]></programlisting> - <variablelist> - <varlistentry> - <term><parameter>id</parameter></term> - <listitem> - <simpara> - A unique string identifying this plugin. By convention this - will follow the java-like class namespace system. - e.g. <constant>com.ximian.evolution.test-plugin</constant> - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>type</parameter></term> - <listitem> - <simpara> - The type name of the plugin loader. Currently <link - linkend="plugin-loaders-lib">shlib</link> and <link - linkend="plugin-loaders-mono">mono</link> are the only - supported values. If no known handler is registered for this - type, the plugin definition is silently ignored. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>domain</parameter></term> - <listitem> - <simpara> - The translation domain for this plugin, as passed to the - <function>dcgettext</function> call of the gettext package. - If not supplied then the default application domain is used - (i.e. "evolution"). This is used to translate - translatable strings for display. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>name</parameter></term> - <listitem> - <simpara> - A short name for the plugin. "Bob's Wonder - Extender" might be suitable. This value will be - translated. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>description</parameter></term> - <listitem> - <simpara> - A longer description of the plugin's purpose. This value will be - translated. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>author</parameter></term> - <listitem> - <simpara> - One of the authors who wrote the plugin. Either - <parameter>name</parameter> or <parameter>email</parameter> - may be ommitted. This element may occur multiple times to - indicate multiple authors. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>hook</parameter></term> - <listitem> - <simpara> - This is a list of all of the hooks that this plugin wishes to - hook into. See the <link linkend="plugin-hooks">Plugin - Hooks</link> section for the details of the basic hook - types defined. - </simpara> - <simpara> - The hook <parameter>class</parameter> is resolved using the - registered hook types, and if none can be found, or a version - mismatch occurs, then the hook is silently ignored. - </simpara> - </listitem> - </varlistentry> - </variablelist> - </sect2> - </sect1> - - <sect1 id="plugin-loaders-lib"> - <title> - Shared Library Loader - </title> - <para> - The shared library loader <link - linkend="API-struct--EPluginLib">EPluginLib</link> implements a - concrete EPlugin type which loads GNU shared libraries via the - GModule api. It simply resolves symbols directly from the loaded - shared object and invokes them expecting a function signature of - <type>EPluginLibFunc</type>. - </para> - <para> - To manage plugin lifecycle, the function - <function>e_plugin_lib_enable</function> - will be invoked which allows the plugin to initialise itself. Its - signature should match <type>EPluginLibEnableFunc</type>, and it will - be called with <parameter>enable=1</parameter>. If the enable - function returns non-zero it is assumed to have failed intialisation - and will not be invoked further. - </para> - - <sect2 id="plugin-loaders-lib-definition"> - <title>Definition</title> - <para>The shared library loader only requires one extra parameter in - the base plugin definition. - </para> - <programlisting> - <![CDATA[ -<e-plugin - ... - type="shlib" - location="/full/path/name.so" - load-on-startup="true" ? - ... - <hook class="..."> - ... -</e-plugin>]]></programlisting> - <variablelist> - <varlistentry> - <term><parameter>type</parameter></term> - <listitem> - <simpara> - The type name of the shared library plugin is - <constant>shlib</constant>. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>location</parameter></term> - <listitem> - <simpara> - The location parameter contains - the full path-name of a shared object to load. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>load-on-startup</parameter></term> - <listitem> - <simpara> - If provided, indicates that the plugin should be loaded and - enabled when the application is first started. Normally the - plugin is only loaded when necessary, i.e. when a callback is - first invoked. Only use this option if you have defined an - <function>e_plugin_lib_enable</function> callback in your - module, and only if absolutely necessary. - </simpara> - </listitem> - </varlistentry> - </variablelist> - </sect2> - - <sect2 id="plugin-loaders-lib-invocation"> - <title>Invocation</title> - <simplesect> - <title>Function specification - </title> - <para>Where a function spec is required in a plugin - hook definition, it should simply be the full name of an - exported symbol in the shared object. - </para> - </simplesect> - <simplesect> - <title>Callback signature</title> - <funcsynopsis><funcprototype> - <funcdef>void * <function>function</function></funcdef> - <paramdef>EPlugin * <parameter>ep</parameter></paramdef> - <paramdef>void * <parameter>data</parameter></paramdef> - </funcprototype></funcsynopsis> - <variablelist> - <varlistentry> - <term><function>function</function></term> - <listitem> - <simpara> - The callback function. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>ep</parameter></term> - <listitem> - <simpara> - The container EPlugin representing this plugin. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>data</parameter></term> - <listitem> - <simpara> - Hook context data. It is part of the hook's api to specify - the type of this pointer. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><returnvalue>return value</returnvalue></term> - <listitem> - <simpara> - Return data. It is part of the hook's api to specify the - type of this pointer. - </simpara> - </listitem> - </varlistentry> - </variablelist> - </simplesect> - </sect2> - </sect1> - - <sect1 id="plugin-loaders-mono"> - <title> - Mono Assembly Loader - </title> - <para> - The mono assembly loader <link - linkend="API-struct--EPluginMono">EPluginMono</link> implements a - concrete EPlugin type which loads C# assemblies using Mono. Apart - from loading the assembly, it can optionally instantiate a class to - implement the callback or invoke static methods directly. - </para> - - <sect2 id="plugin-loaders-mono-definition"> - <title>Definition</title> - <para>The mono assembly loader needs the name of the assembly and - optionally the name of the class for handling the callbacks. - </para> - <programlisting> - <![CDATA[ -<e-plugin - ... - type="mono" - location="/full/path/name.dll" - handler="PluginClass" ? - ... - <hook class="..."> - ... -</e-plugin>]]></programlisting> - <variablelist> - <varlistentry> - <term><parameter>type</parameter></term> - <listitem> - <simpara> - The type name of a mono assembly plugin is - <constant>mono</constant>. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>location</parameter></term> - <listitem> - <simpara> - The location parameter contains - the full path-name of an assembly to load. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>handler</parameter></term> - <listitem> - <simpara> - If supplied, the handler contains the fully qualified name of - the class which handles all callbacks for this plugin. If a - handling class is used, then the function specifications - become relative to this class. - </simpara> - <simpara> - This class will be - instantiated once upon the first callback invocation, and - remain active for the life of the plugin (or application). - </simpara> - </listitem> - </varlistentry> - </variablelist> - </sect2> - - <sect2 id="plugin-loaders-mono-invocation"> - <title>Invocation</title> - <simplesect> - <title>Function specification - </title> - <para>If no <parameter>handler</parameter> class is specified, then - the function specification must match a static method in the - assembly. This is passed to <function>mono_method_desc_new</function> - and <function>mono_method_desc_search_in_image</function>, - typically <function>FunctionName(intptr)</function>. - </para> - <para> - If the handler is specified, then the function specification is - relative to the handler class. This is passed to - <function>mono_method_desc_new</function> and - <function>mono_method_desc_search_in_class</function>, typically - <function>:MethodName(intptr)</function>. - </para> - </simplesect> - <simplesect> - <title>Callback signature</title> - <funcsynopsis><funcprototype> - <funcdef>IntPtr <function>function</function></funcdef> - <paramdef>IntPtr <parameter>data</parameter></paramdef> - </funcprototype></funcsynopsis> - <variablelist> - <varlistentry> - <term><function>function</function></term> - <listitem> - <simpara> - The callback method. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>data</parameter></term> - <listitem> - <simpara> - The hook context data. This is a pointer to unmanaged data, and it is up-to the plugin to interpret this - data right now, although some helper binding classes are - planned. FIXME: hook-up when they and doco are done. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><returnvalue>return value</returnvalue></term> - <listitem> - <simpara> - The callback return data. It is up to the hook's api to - define the type of this pointer. It may be a simple boxed - value type, or a memory pointer allocated in unmanaged memory (e.g. a - GObject handle or a CamelObject cobject value). - </simpara> - </listitem> - </varlistentry> - </variablelist> - </simplesect> - </sect2> - </sect1> - - </chapter> - - <chapter id="plugin-hooks"> - <title> - Plugin Hooks - </title> - <para> - This chapter will introduce the available plugin hook types. A given - plugin can hook into any of these hooks any number of times. Some refer - to specific instances of objects and others are implicitly defined. - </para> - <para> - By design, there is considerable similarity and orthogonality amongst - all of the various hook types and management objects. - </para> - <sect1 id="plugin-hooks-popup"> - <title> - Popup Menus - </title> - <para> - The popup menu hook lets you hook into any of the context menus in - &Evolution;, by name and context. Complex, dynamic, and multi-level - menus are created on the fly by merging the items for a given menu as - it is being shown. Each component provides its own context targets to - self-describe the situation under which the menu is invoked. Plugins - and core code alike are then invoked at the user's direction. The - popup manager and all context data lives as long as the menu and - until a choice is made, simplifying memory management. - </para> - <para> - The menu is merged from multiple plugins and core application code by - using a simple lexiographical sort of an absolute path to the menu - item. This merged list is then scanned and expanded into a tree of - menus. Individual items can be hidden or inactive based on the target - and a simple mask which is defined by the component itself. A rich - collection of menu item types are possible, from simple, to - checkboxes or images. The popup code is simple, and easy to use, and - simplifies the use of popup menu's in the core application anyway, - that they are pluggable is a free-bonus. - </para> - <sect2> - <title>Defining a popup hook</title> - <para> - Not sure if this fits here as such. Probably temporary placeholder. - </para> - <programlisting> - <![CDATA[ -<hook class="com.ximian.evolution.mail.popup:1.0"> - <menu id="menuid" target="targettype"> - <item - type="item | toggle | radio | image | submenu | bar" - active ? - path="foo/bar" - label="menu text" - icon="icon name" ? - visible="target mask" ? - enable="target mask" ? - activate="function spec"/> * - </menu> * -</hook>]]></programlisting> - <!-- this is all too bloody verbose, is there a better way? --> - <para> - <emphasis>Need to define menu tag</emphasis> - </para> - <variablelist> - <varlistentry> - <term><parameter>type</parameter></term> - <listitem> - <simpara> - The menu item type. The type maps directly to the - corresponding EPopupItem types. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>active</parameter></term> - <listitem> - <simpara> - If present, then radio or toggle menu items are active when - first shown. After the first instantiation, they will - remember their active state. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>path</parameter></term> - <listitem> - <simpara> - A '/' separated path used to position the item within menu - and in the right submenu. Each menu and plugin should - define how its menu's are layed out so other plugins can - determine what value to use here. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>label</parameter></term> - <listitem> - <simpara> - The text to be displayed on the menu item. This will be - translated based on the plugin translation domain. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>icon</parameter></term> - <listitem> - <simpara> - The name of a gnome-icon-theme standard icon, or the full - path-name of an icon image to use as menu item icon. This - will be blank if not supplied. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>visible</parameter></term> - <listitem> - <simpara> - A comma separated list of mask enumeration values used to - define when this item is shown. What values are valid - depend on the menu hook class of the menu being hooked - onto. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>enable</parameter></term> - <listitem> - <simpara> - A comma separated list of mask enumeration values used to - define when this item is enabled. What values are valid - depend on the menu hook class of the menu being hooked - onto. This is currently unimplemented. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>activate</parameter></term> - <listitem> - <simpara> - A plugin-type specific function specification. This - function will be resolved and called when the menu item is - activated. - </simpara> - </listitem> - </varlistentry> - </variablelist> - </sect2> - <sect2> - <title>Merging Plugin Items</title> - <para> - A very simple algorithm is used to form the menu by merging the - plugin's menu items with the system menu items for a given menu. - What follows is a simple example of how this is done. It will be - demonstrated using a simplified menu from the message-list, as used - in the &Evolution; Mail component, and a simple plugin which adds a - single menu item and menu separator into the middle of the menu, - when appropriate. - </para> - <para> - When the application wishes to show a specific popup menu, it - creates a new EPopup object with a unique menu id to manage it. It - adds all of the items it wishes to add to the menu (see "Builtin - Items" in the following diagrams). The application then asks for - the menu to be created. The menu building - process adds all of the menu items from all plugins that target - this specific menu into a flat list, discarding those which don't - match the current Target qualifications. The result is then - sorted using a simple ASCII sort, and then a menu built from the - remaining items. This is probably best described by some diagrams. - </para> - <para> - The following two diagrams show how a popup menu is automatically - customised depending on the context. On the left of each diagram - are all of the menu items which apply to the example menu. The - menu label, with the qualifiers listed underneath, with the menu - item path along-side. On the right-hand side of each diagram is - the result of: - </para> - <itemizedlist> - <listitem><simpara>Selecting items based on the target - qualifiers</simpara></listitem> - <listitem><simpara>Sorting the remaining items based on their - path.</simpara></listitem> - <listitem><simpara>Building this sorted list into a - menu.</simpara></listitem> - </itemizedlist> - - <para> - The actual list of target qualifiers are defined by the application - itself. Generally a specific menu will have only one possible - target, and a list of matching target qualifiers. The example - shows how a plugin can insert a menu item anwhere it wishes in the - menu system. Submenus are also supported, and they work in exactly - the same manner, with / characters used to separate submenu paths. - A submenu must sort into the position immediately before the - definition of its items. - </para> - - <figure id="e-popup-merge-1"> - <title>Merging a menu with many items selected.</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/e-popup-merge-1.pic" format="PIC" /> - </imageobject> - <imageobject> - <imagedata fileref="images/e-popup-merge-1.eps" format="EPS"/> - </imageobject> - <imageobject> - <imagedata fileref="images/e-popup-merge-1.png" format="PNG"/> - </imageobject> - <textobject> - <phrase>Showing how a display list of menu items is selected - and then sorted for display.</phrase> - </textobject> - </mediaobject> - </figure> - - <para> - The first diagram shows when the target qualifiers are - <parameter>many</parameter>, and - <parameter>mark_unread</parameter>. The menu items which operate - on only one selected message are not shown. Similarly for those - able to be marked as unread (i.e. they are currently read). - </para> - - <figure id="e-popup-merge-2"> - <title>Merging a menu with one item selected.</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/e-popup-merge-2.pic" format="PIC"/> - </imageobject> - <imageobject> - <imagedata fileref="images/e-popup-merge-2.eps" format="EPS"/> - </imageobject> - <imageobject> - <imagedata fileref="images/e-popup-merge-2.png" format="PNG"/> - </imageobject> - <textobject> - <phrase>Showing how a display list of menu items is selected - and then sorted for display with different qualifiers.</phrase> - </textobject> - </mediaobject> - </figure> - - <para> - This diagram shows when the target qualifiers are - <parameter>one</parameter>, and - <parameter>mark_read</parameter>. The menu items which operate - on only many selected messages are not shown. Similarly for those - able to be marked as read. - </para> - </sect2> - </sect1> - - <sect1 id="plugin-hooks-menu"> - <title> - Main menus - </title> - <para> - The main menu hook lets you hook into various main menus in - &Evolution;, based on the current active view (component). The system - works by piggy-backing on the existing use of the BonoboUI menu - system used by all of the &Evolution; components. Bonobo handles the - menu merging and user input, and the hook resolves the verb being - invoked and redirects it to the plugin. Each view defines a single - target which describes the appropriate context. For the Mail view, - this is the current folder and currently selected message(s). - </para> - <para> - Each view keeps track of its own manager object. When it is - (de)activated, it also (de)activates the management object which - dynamically adds and removes the menu items from the - BonoboUIContainer via a supplied BonoboUI XML definition file - <perhaps it should embed the bonobouixml>. If the target - changes, the view lets the manager know, and it updates the - visibility and sensitivity of objects appropriately, allowing - reasonably dynamic user-interfaces to be managed automatically. The - plugin itself isn't loaded until the menu item in question is invoked - </para> - <para> - Simple menu items and toggle menu items are supported currently. - Also, because actual menu display is driven by BonoboUI, then toolbar - items can also be added using this mechanism. - </para> - <sect2> - <title>Defining a menu hook</title> - <para> - Not sure if this fits here as such. Probably temporary placeholder. - </para> - <programlisting> - <![CDATA[ -<hook class="com.ximian.evolution.mail.bonoboMenu:1.0"> - <menu id="menuid" target="targettype" - <ui file="/path/to/bonobo-ui-menu-definition.xml"> + - <item - type="item | toggle | radio" - active ? - path="/commands/FooBar" - verb="FooBar" - visible="target mask" ? - enable="target mask" ? - activate="function spec"/> * - </menu> * -</hook>]]></programlisting> - <para> - <emphasis>Need to define menu tag</emphasis> - </para> - <variablelist> - <varlistentry> - <term><parameter>ui</parameter></term> - <listitem> - <simpara> - The <parameter>ui</parameter> element contains a filename of the - BonoboUI XML menu definition to load when the view is activated. Any number of - <parameter>ui</parameter> elements may be defined, and they - are all loaded. - </simpara> - </listitem> - </varlistentry> - - <varlistentry> - <term><parameter>type</parameter></term> - <listitem> - <simpara> - The menu item type. The type maps directly to the - corresponding EMenuItem types. - <parameter>radio</parameter> is currently not implemented. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>active</parameter></term> - <listitem> - <simpara> - If present, then radio or toggle menu items are active when - first shown. After the first instantiation, they will - remember their active state. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>path</parameter></term> - <listitem> - <simpara> - The BonoboUI element path corresponding to this menu item. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>verb</parameter></term> - <listitem> - <simpara> - The BonoboUI verb corresponding to the item to be listened to. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>visible</parameter></term> - <listitem> - <simpara> - A comma separated list of mask enumeration values used to - define when this item is shown. What values are valid - depend on the menu hook class of the menu being hooked - onto. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>enable</parameter></term> - <listitem> - <simpara> - A comma separated list of mask enumeration values used to - define when this item is sensitive. What values are valid - depend on the menu hook class of the menu being hooked - onto. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>activate</parameter></term> - <listitem> - <simpara> - A plugin-type specific function specification. This - function will be resolved and called when the menu item is - activated. The funciton's parameters will depend on the type - of menu item being invoked. - </simpara> - </listitem> - </varlistentry> - </variablelist> - </sect2> - <sect2> - <title>Merging Plugin Items</title> - <para> - Merging is performed by BonoboUI, and the source of the menu data - is defined by the <parameter>ui</parameter> file. - </para> - </sect2> - </sect1> - - <sect1 id="plugin-hooks-config"> - <title> - Configuration Pages and Wizards - </title> - <para> - Configuration pages are somewhat more complex than any of the other - types of hookable object. This is reflected in the complexity of the - items and callbacks involved. - </para> - <para> - Essentially, the EConfig object is used in combination to both - instrument existing windows and building new content. Each - configuration window comprises of several basic elements with some - minor variations allowed. It consists of a number of pages in a - specific order, each containing a number of titled sections in a specific - order, each containing a number of items. The variations are that - the top-level widget may be a GtkNotebook or a GnomeDruid; and each - section may instrument a GtkBox, or a GtkTable. The definition of - the available hooks will define what form they take. - </para> - <para> - The EConfig manager uses the description of all the items supplied to - it to build the complete window. It can also drive various aspects - of the UI, such as navigating through a druid or handling - instant-apply vs. modify-and-save dialogues. - </para> - <figure id="e-config-flow"> - <title>Event and Data Flow in EMConfig</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/e-config-flow.pic" format="PIC"/> - </imageobject> - <imageobject> - <imagedata fileref="images/e-config-flow.eps" format="EPS"/> - </imageobject> - <imageobject> - <imagedata fileref="images/e-config-flow.png" format="PNG"/> - </imageobject> - <textobject> - <phrase>The flow of information and control signals in the - configuration management object.</phrase> - </textobject> - </mediaobject> - </figure> - - <sect2> - <title>Defining a configuration page hook</title> - <para> - Not sure if this fits here as such. Probably temporary placeholder. - </para> - <programlisting> - <![CDATA[ -<hook class="com.ximian.evolution.mail.config:1.0"> - <group - id="window id" - target="targettype" - check="function spec"? - commit="function spec"? - abort="function spec"?> - <item - type="book | druid | page | page_start | page_finish | section | section_table | item" - path="/absolute/path" - label="name" | factory="function spec" - /> * - </menu> * -</hook>]]></programlisting> - - <sect3> - <title>Group Element Properties</title> - - <variablelist> - <varlistentry> - <term><parameter>id</parameter></term> - <listitem> - <simpara> - The name of the configuration window to which this hook - applies. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>target</parameter></term> - <listitem> - <simpara> - The type of target this configuration window applies too. - This will normally be tied directly to the specific - configuration window itself. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>check</parameter></term> - <listitem> - <simpara> - A callback which will be invoked to validate the - configuration or a specific page of the configuration. It - will be invoked with a - <link - linkend="API-struct--EConfigHookPageCheckData">EConfigHookPageCheckData</link> - structure, and is expected to return a non-NULL value if - the page validates. - </simpara> - <simpara> - The callback will be expected to handle all - <parameter>pageid</parameter>'s present in the - configuration window, and should return - <constant>TRUE</constant> for pages it does not recognise. - If <parameter>pageid=""</parameter> (an empty - string), then the <parameter>check</parameter> function - should validate all settings. See also <xref - linkend="API-e-config-add-page-check" />. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>commit</parameter></term> - <listitem> - <simpara> - A callback which will be invoked to commit the - configuration data, if the configuration page isn't an - instant-apply one. This callback can write any - configuration changes to permanent storage. It is not used - for instant-apply windows. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>abort</parameter></term> - <listitem> - <simpara> - A callback which will be invoked to abort the configuration - process. This callback is called when the - <guibutton>Cancel</guibutton> button is pressed on stateful - configuration windows. - </simpara> - </listitem> - </varlistentry> - </variablelist> - </sect3> - <sect3> - <title>Item Element Properties</title> - - <variablelist> - <varlistentry> - <term><parameter>type</parameter></term> - <listitem> - <simpara> - The menu item type. The type maps directly to the - corresponding EConfigItem types. Only one of - <parameter>book</parameter> and <parameter>druid</parameter> - may be supplied for the entire configuration page, and this - will usually already be defined by the application. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>path</parameter></term> - <listitem> - <simpara> - The path to the configuration item in question. This is a - simple string that when sorted using an ASCII sort will place - the items in the right order. That is, sections before items - before pages before the root object. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>label</parameter></term> - <listitem> - <simpara> - The textual label of this item. This may only be supplied - for the section and page types. For sections it will be the - section frame text. For pages this will be the druid page - title or the notebook tab text. If a - <parameter>factory</parameter>is supplied then this value is - not used. This will be translated based on the plugin - translation domain. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>factory</parameter></term> - <listitem> - <simpara> - If supplied, the factory method used to create the GtkWidget - elements for this configuration item. Factories may be - supplied for any of the item types. If no - <parameter>label</parameter> is set then the - <parameter>factory</parameter> must be set. - </simpara> - </listitem> - </varlistentry> - </variablelist> - </sect3> - </sect2> - <sect2> - <title>Generating Configuration Pages</title> - <para> - Configuration items essentially spam 3 dimensions, but are - merged in a similar fashion to the way Popup items are merged. The - main difference is that there are no target qualifiers used to - select which items are shown, it is up to the item factory to - either create or not create the item as it sees fit. The EConfig - manager takes care of the rest, including removing un-used sections - or pages. - </para> - <para> - All items for a given configuration screen are converted into a - list and sorted based on the <parameter>path</parameter>. The - configuration builder then goes through each item, creating - container widgets or calling factories as required. If a given - page or section is empty, then it is removed automatically. This - process isn't only a one-off process. For certain complex - configuration screens, items or even pages and sections need to be - dynamic based on a previous setting. EConfig supports this mode of - operation too, in which case it re-builds the configuration screen - the same way, and automatically destroys the old widgets - <footnote><simpara>In most cases, in some cases additional manual - processing is required in the factory - callback.</simpara></footnote> and even re-orders pages and - sections where appropriate to make the user-interface consistent. - </para> - <para> - The following few examples some of the flexibility of the EConfig - system. - </para> - <figure id="e-config-build-1"> - <title>The application defined, unaltered configuration page.</title> - <mediaobject> - <!-- do we need to build our own eps for the image? --> - <imageobject> - <imagedata fileref="images/e-config-build-1.png" format="PNG"/> - </imageobject> - <textobject> - <phrase>Shows the original HTML Mail settings page.</phrase> - </textobject> - </mediaobject> - </figure> - <para> - First we have the original configuration window. This is defined - by the application, the application uses EConfig to build this - window, and in the process EConfig instruments the sections that - the application defines. This allows plugins to add new - pages/sections/items anywhere on the page - to a granularity as - defined by the application. For example the application may at - minimum merely define the top-level notebook or druid object and a - number of pages. When the pages are created the application could - add as much content as it wants, which would still allow plugins to - extend the user interface, but only by adding options to the end of - each page. At the other end of the scale the application could - enumerate every single item (i.e. row) in every section on every - page, allowing plugins to put new items anywhere in the display. - </para> - <figure id="e-config-build-2"> - <title>A plugin adding a new section to an existing page.</title> - <mediaobject> - <!-- do we need to build our own eps for the image? --> - <imageobject> - <imagedata fileref="images/e-config-build-2.png" format="PNG"/> - </imageobject> - <textobject> - <phrase>Shows the HTML Mail settings page with a new section - and item added by a plugin.</phrase> - </textobject> - </mediaobject> - </figure> - <para> - In this case the plugin has merely added a new section on the - bottom of the HTML Mail settings page. When the factory is called - the plugin has a parent GtkTable (in this case, it could be a VBox) - and borderless frame already defined, and it just has to - instantiate its own control widgets, add them to the table, and - return one of the widgets. The returned widget is used later if - the window needs to be reconfigured, although this particular configuration - page is static so it isn't needed. - </para> - <figure id="e-config-build-3"> - <title>A plugin inserting a new page for its settings.</title> - <mediaobject> - <!-- do we need to build our own eps for the image? --> - <imageobject> - <imagedata fileref="images/e-config-build-3.png" format="PNG"/> - </imageobject> - <textobject> - <phrase>Shows the plugin adding a new page for its setting as - an alternative.</phrase> - </textobject> - </mediaobject> - </figure> - <para> - And finally we have exactly the same plugin, which has exactly the - same code. But a small change to the plugin definition allows the - plugin to add an arbitrary new page (in an arbitrary position) into - the whole window. If this was a druid, then new druid pages can - also be inserted at arbitrary locations, and page navigation (in a - strictly linear manner) is automatically controlled by EConfig as - per <xref linkend="e-config-flow"/>. - </para> - <para> - In practice, EConfig provides more than it takes the application to - use - generally little or no extra application code is required to - use it. It also - <footnote><simpara>Or it will - the code needs some - tweaking.</simpara></footnote> enforces and simplifies HIG - compliance. And as a side-benefit to the application it - transparently provides extension hooks for - external code to provide a seamlessly integrated user experience. - </para> - </sect2> - </sect1> - - <sect1 id="plugin-hooks-event"> - <title> - Events - </title> - <para> - No extensibility framework would be complete without an event - system. Events are used to reflect changes in internal state of the - application, and track actions by the user. They can contain any - information and additionally can be filtered based on the information - itself. Special targets are used, as in the other plugin hooks, to - hold this information. - </para> - <para> - Event managers are defined to contain the different event types that - a given component can export. Only one event manager object is - instantiated for each component, and each plugin listening to events - from that component are registered on that event manager directly. - </para> - <para> - Events handlers have priorities, and can swallow events, allowing - some level of complexity of event routing. This feature might not - prove useful and may be removed in the future if it isn't. - </para> - <sect2> - <title>Defining an event hook</title> - <para> - Not sure if this fits here as such. Probably temporary placeholder. - </para> - - <programlisting> - <![CDATA[ -<hook class="com.ximian.evolution.mail.events:1.0"> - <event - target="target name" - id="event name" - type="pass | sink" ? - priority="signed integer" ? - enable="target mask" ? - handle="function spec"/> * -</hook>]]></programlisting> - <variablelist> - <varlistentry> - <term><parameter>target</parameter></term> - <listitem> - <simpara> - The target type of the event listener. This will normally - match in a 1:1 relationship to the event - <parameter>id</parameter> itself. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>id</parameter></term> - <listitem> - <simpara> - The name of the event to listen to. By convention the names - will be of the form - <constant>target.event</constant>. - e.g. <constant>folder.changed</constant>, or - <constant>message.read</constant>, etc. Although they are - just simple case-sensitive strings. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>type</parameter></term> - <listitem> - <simpara> - The event listener type. The type maps directly to the corresponding - corresponding EEventItem types. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>priority</parameter></term> - <listitem> - <simpara> - A signed integer specifying the priority of this event - listener. 0 (zero) should be used normally, although positive - and negative integers in the range -128 to 127 may aslo be - used. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>enable</parameter></term> - <listitem> - <simpara> - A comma separated list of mask enumeration values used to - qualify when this event listener is invoked. What values are valid - depend on the event hook class. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>handle</parameter></term> - <listitem> - <simpara> - A plugin-type specific function specification. This - function will be resolved and called when an event is routed to - this listener. - </simpara> - </listitem> - </varlistentry> - </variablelist> - </sect2> - </sect1> - - <sect1 id="plugin-hooks-format"> - <title> - Mail Formatter - </title> - <para> - The mail formatter plugin will invoke plugin code to format any part - of an email based on mime-type. There are several formatters used - internally by the mailer for different contexts, and each can be - hooked into separately, providing extensible mail formatting for - everything from the primary mail display, to printing, to reply - quoting and more. If you are implementing a handler for a given - mime-type, each formatter appropriate for the data-type should be - hooked into, so that it displays properly in all contexts. - </para> - <para> - Since the management object in this case is the same formatting - object as used by the core mail display engine, a plugin may override - or reimplement complete new functionality seamlessly. - </para> - <para> - This plugin hook isn't strictly part of the core functionality as it - is provided only by the mail component. It however demonstrates that the - plugin system is extensible itself. - </para> - <sect2> - <title>Defining a formatter hook</title> - <para> - Not sure if this fits here as such. Probably temporary placeholder. - </para> - - <programlisting> - <![CDATA[ -<hook class="com.novell.evolution.mail.format:1.0"> - <group id="formatter type"> - <item - flags="handler flags" - mime_type="major/minor" - format="function spec"/> + - </group> + -</hook>]]></programlisting> - <variablelist> - <varlistentry> - <term><parameter>id</parameter></term> - <listitem> - <simpara> - The actual formatter this applies to. e.g. EMFormat for the - base formatter class, EMFormatHTML for HTML output to a - GtkHTML object, etc. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>flags</parameter></term> - <listitem> - <simpara> - Flags to define whether this is an attachment or inline - content. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>id</parameter></term> - <listitem> - <simpara> - The name of the event to listen to. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>mime_type</parameter></term> - <listitem> - <simpara> - The type of object this handler formats. - </simpara> - </listitem> - </varlistentry> - <varlistentry> - <term><parameter>format</parameter></term> - <listitem> - <simpara> - A plugin-type specific function specification. This - function will be invoked to format objects of the specified - <parameter>mime_type</parameter>. - </simpara> - </listitem> - </varlistentry> - </variablelist> - </sect2> - - <sect2> - <title>The formatting process</title> - <para> - The formatting process is driven by the <link - linkend="API-struct--EMFormat">EMFormat</link> object, although - there are different subclasses of this object used for different - purposes. These behave quite differently so each must be explained - separately. There is the basic formatter type which converts a - CamelMimeMessage into a stream of data, and there is a HTML - <link linkend="API-struct--EMFormatHTML">formatter type</link> - which uses a GtkHTML object to parse the content - and may request further information required to complete the - formatting. - </para> - <para> - A basic formatter goes through the following steps: - </para> - <orderedlist> - <listitem> - <simpara>Outputs pre-amble information. e.g. Flag-For-Followup - status.</simpara> - </listitem> - <listitem> - <simpara>Invokes <methodname>format_message</methodname> to begin the message - formatting. <methodname>format_message</methodname> displays the message header, then - looks up the content object.</simpara> - </listitem> - <listitem> - <simpara>Using the mime-type of the content object (whether - supplied or calculated), a handler is looked up from a - per-class table to process the type.</simpara> - </listitem> - <listitem> - <simpara>If no handler exists, then the data is formatted as an - attachment.</simpara> - </listitem> - <listitem> - <simpara>If a handler exists, then it is invoked to display that - type. Depending on whether the data is to be displayed - 'inline' or not, the data may also get an attachment expander - and button.</simpara> - </listitem> - <listitem> - <simpara>The handler transforms the part's data, if need be, and - writes the appropriate format output to a stream.</simpara> - </listitem> - </orderedlist> - <para> - For conglomerate types, the formatting process is continued - recursively, until all parts have been displayed, as appropriate. - </para> - <para> - A HTML formatter goes through the same basic steps, but has - additional features and requirements. It uses multiple - threads. At least one other thread is used for all of the - Camel message content operations since some of them may block on - remote I/O. This also simplifies cancellation processing. Also, - because it has access to a full HTML rendering object, references - to embedded content (images, buttons, etc.) are also processed. - </para> - <para> - Most format handlers don't need to know about all the fiddly - details however. If they are just outputting HTML content with no - out of band references, they work identical to the basic format - handlers with the exception they cannot call any Gtk GUI code - because of threading issues. This can still be done by using an - IFRAME. If they want to embed an icon or other image, - they simply need to insert the HTML IMG tag reference in their - format handler, and setup a callback to handle it when GtkHTML - requests it. EMFormat has some helper classes to make this - only a few lines of code, including generation of the IMG SRC URL. - IFRAMEs work identically to IMG tags, and similar process is - involved with embedding custom widgets using the OBJECT tag. - EMFormatHTML takes care of calling the right callbacks for the - right embedded reference from the right thread. - </para> - <para> - Since format handlers are chained off a given type, then a plugin - can also inherit formatting behaviour as well as override it. This - gives much greater flexibility since the plugin need only implement - its behaviour in specific situations. e.g. an OpenPGP message - handler could fall-back to the normal text-formatter if it doesn't - detect the ASCII armour in a text/plain part. Or another handler - may disable itself based on configuration or state. - </para> - <para> - All format handlers for all types must also be fully re-entrant - code (more or less write-once global and static variables) if - they call any other formatting functions. - </para> - </sect2> - </sect1> - </chapter> - </part> - - <part> - <title> - &Evolution; Hook Points. - </title> - <partintro> - <para> - This section enumerates all of the published hook points and target - types available in each component in &Evolution;. - </para> - - <simplesect> - <title>Table Format</title> - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody> - <row> - <entry>Id</entry> - <entry>The hook point id.</entry> - </row> - <row> - <entry>Target</entry> - <entry>The target which this hook uses for its context data. - Targets are described in a following section. - </entry> - </row> - <row> - <entry>Items</entry> - <entry>If appropriate and defined, specifies identifying path - names of items which make up the hook. e.g. popup menu - items, and configuration pages. These item specifications - allow the plugin writer to position their items - appropriately. - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </simplesect> - - </partintro> - <chapter id="mail-hooks"> - <title> - Mail Hooks - </title> - <para> - <emphasis> - Need to find out the right docbook to mark-up most of this - text. - </emphasis> - </para> - - <sect1 id="mail-hooks-popup"> - <title>Popup menus</title> - - <para> - The mail popup menu class is - <interfacename>org.gnome.evolution.mail.popup:1.0</interfacename>. - </para> - <para> - The plugin callback data will be the target matching the plugin - menu itself, and the callback returns no value. - </para> - - &em-popups; - - <sect2> - <title>Internal popup menus</title> - <para> - The following popup menus are defined, but they are used with no - target, and so provide no useful context if they were to be hooked - onto. - </para> - <para> - <interfacename>com.ximian.mail.messagelist.popup.drop</interfacename> - is used for the ASK drop type on the message list. - </para> - <para> - <interfacename>com.ximian.mail.storageset.popup.drop</interfacename> - is used for the ASK drop type on the folder tree. - </para> - </sect2> - - <sect2> - <title>Mail Popup Targets</title> - - <para> - <emphasis> - Not sure if this needs to explain the qualifier meanings, or - leave it to the in-line comment stuff in the enumeration - definition. Maybe it just needs a direct link to the - enumeration. - </emphasis> - </para> - - <sect3 id="mail-hooks-popup-EMPopupTargetFolder"> - <title>Folder Target</title> - - <para> - This target is used to define actions on a folder context. - Normally associated with the folder tree. - </para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>folder</constant></entry> - </row> - <row> - <entry>Structure</entry> - <entry> - <link - linkend="API-struct--EMPopupTargetFolder">EMPopupTargetFolder</link> - </entry> - </row> - <row> - <entry>Qualifiers</entry> - <entry> - <simplelist> - <member><constant>folder</constant> = <constant>EM_POPUP_FOLDER_FOLDER</constant></member> - <member><constant>store</constant> = <constant>EM_POPUP_FOLDER_STORE</constant></member> - <member><constant>inferiors</constant> = <constant>EM_POPUP_FOLDER_INFERIORS</constant></member> - <member><constant>delete</constant> = <constant>EM_POPUP_FOLDER_DELETE</constant></member> - <member><constant>select</constant> = <constant>EM_POPUP_FOLDER_SELECT</constant></member> - </simplelist> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect3> - - <sect3 id="mail-hooks-popup-EMPopupTargetSelect"> - <title>Selection Target</title> - - <para>This target is used to define context for actions associated - with a selection of mail messages from a specific folder.</para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>select</constant></entry> - </row> - <row> - <entry>Structure</entry> - <entry> - <link - linkend="API-struct--EMPopupTargetSelect">EMPopupTargetSelect</link> - </entry> - </row> - <row> - <entry>Qualifiers</entry> - <entry> - <simplelist> - <member><constant>one</constant> = <constant>EM_POPUP_SELECT_ONE</constant></member> - <member><constant>many</constant> = <constant>EM_POPUP_SELECT_MANY</constant></member> - <member><constant>mark_read</constant> = <constant>EM_POPUP_SELECT_MARK_READ</constant></member> - <member><constant>mark_unread</constant> = <constant>EM_POPUP_SELECT_MARK_UNREAD</constant></member> - <member><constant>delete</constant> = <constant>EM_POPUP_SELECT_DELETE</constant></member> - <member><constant>undelete</constant> = <constant>EM_POPUP_SELECT_UNDELETE</constant></member> - <member><constant>mailing_list</constant> = <constant>EM_POPUP_SELECT_MAILING_LIST</constant></member> - <member><constant>resend</constant> = <constant>EM_POPUP_SELECT_EDIT</constant></member> - <member><constant>mark_important</constant> = <constant>EM_POPUP_SELECT_MARK_IMPORTANT</constant></member> - <member><constant>mark_unimportant</constant> = <constant>EM_POPUP_SELECT_MARK_UNIMPORTANT</constant></member> - <member><constant>flag_followup</constant> = <constant>EM_POPUP_SELECT_FLAG_FOLLOWUP</constant></member> - <member><constant>flag_completed</constant> = <constant>EM_POPUP_SELECT_FLAG_COMPLETED</constant></member> - <member><constant>flag_clear</constant> = <constant>EM_POPUP_SELECT_FLAG_CLEAR</constant></member> - <member><constant>add_sender</constant> = <constant>EM_POPUP_SELECT_ADD_SENDER</constant></member> - <member><constant>mark_junk</constant> = <constant>EM_POPUP_SELECT_MARK_JUNK</constant></member> - <member><constant>mark_nojunk</constant> = <constant>EM_POPUP_SELECT_MARK_NOJUNK</constant></member> - <member><constant>folder</constant> = <constant>EM_POPUP_SELECT_FOLDER</constant></member> - </simplelist> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect3> - - <sect3 id="mail-hooks-popup-EMPopupTargetURI"> - <title>URI Target</title> - - <para>This target defines context for operations on a URI, normally - displayed inline somewhere in the message view.</para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>uri</constant></entry> - </row> - <row> - <entry>Structure</entry> - <entry><link - linkend="API-struct--EMPopupTargetURI">EMPopupTargetURI</link></entry> - </row> - <row> - <entry>Qualifiers</entry> - <entry> - <simplelist> - <member><constant>http</constant> = <constant>EM_POPUP_URI_HTTP</constant></member> - <member><constant>mailto</constant> = <constant>EM_POPUP_URI_MAILTO</constant></member> - <member><constant>notmailto</constant> = <constant>EM_POPUP_URI_NOT_MAILTO</constant></member> - </simplelist> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect3> - - <sect3 id="mail-hooks-popup-EMPopupTargetPart"> - <title>Message Part Target</title> - - <para>This target defines context for operations on messages, or - individual message parts. The same target is used for inline - images or other content which can be encapsulated in a MIME part - (i.e. anything).</para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>part</constant></entry> - </row> - <row> - <entry>Structure</entry> - <entry><link - linkend="API-struct--EMPopupTargetPart">EMPopupTargetPart</link></entry> - </row> - <row> - <entry>Qualifiers</entry> - <entry> - <simplelist> - <member><constant>message</constant> = <constant>EM_POPUP_PART_MESSAGE</constant></member> - <member><constant>image</constant> = <constant>EM_POPUP_PART_IMAGE</constant></member> - </simplelist> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect3> - - <sect3 id="mail-hooks-popup-EMPopupTargetAttachments"> - <title>Attachments Target</title> - - <para>This target is used to define context for operations on the - mail composer attachment bar.</para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>attachments</constant></entry> - </row> - <row> - <entry>Structure</entry> - <entry><link - linkend="API-struct--EMPopupTargetAttachments">EMPopupTargetAttachments</link></entry> - </row> - <row> - <entry>Qualifiers</entry> - <entry> - <simplelist> - <member><constant>one</constant> = <constant>EM_POPUP_ATTACHMENTS_ONE</constant></member> - <member><constant>many</constant> = <constant>EM_POPUP_ATTACHMENTS_MANY</constant></member> - </simplelist> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect3> - - </sect2> - </sect1> - - <sect1 id="mail-hooks-menu"> - <title>Main menus</title> - - <para> - The mail popup menu class is - <interfacename>org.gnome.evolution.mail.bonobomenu:1.0</interfacename>. - </para> - <para> - The plugin callback data will be the target matching the plugin - menu itself, and the callback returns no value. - </para> - - &em-menus; - - <sect2> - <title>Mail Menu Targets</title> - - <sect3 id="mail-hooks-menu-EMMenuTargetSelect"> - <title>Message Selection Target</title> - - <para>This target is used to define context for operations on a - selection of messages in the view's message list.</para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>select</constant></entry> - </row> - <row> - <entry>Structure</entry> - <entry> - <link - linkend="API-struct--EMMenuTargeSelect">EMMenuTargetSelect</link> - </entry> - </row> - <row> - <entry>Qualifiers</entry> - <entry> - <simplelist> - <member><constant>one</constant> = <constant>EM_MENU_SELECT_ONE</constant></member> - <member><constant>many</constant> = <constant>EM_MENU_SELECT_MANY</constant></member> - <member><constant>mark_read</constant> = <constant>EM_MENU_SELECT_MARK_READ</constant></member> - <member><constant>mark_unread</constant> = <constant>EM_MENU_SELECT_MARK_UNREAD</constant></member> - <member><constant>delete</constant> = <constant>EM_MENU_SELECT_DELETE</constant></member> - <member><constant>undelete</constant> = <constant>EM_MENU_SELECT_UNDELETE</constant></member> - <member><constant>mailing_list</constant> = <constant>EM_MENU_SELECT_MAILING_LIST</constant></member> - <member><constant>resend</constant> = <constant>EM_MENU_SELECT_EDIT</constant></member> - <member><constant>mark_important</constant> = <constant>EM_MENU_SELECT_MARK_IMPORTANT</constant></member> - <member><constant>mark_unimportant</constant> = <constant>EM_MENU_SELECT_MARK_UNIMPORTANT</constant></member> - <member><constant>flag_followup</constant> = <constant>EM_MENU_SELECT_FLAG_FOLLOWUP</constant></member> - <member><constant>flag_completed</constant> = <constant>EM_MENU_SELECT_FLAG_COMPLETED</constant></member> - <member><constant>flag_clear</constant> = <constant>EM_MENU_SELECT_FLAG_CLEAR</constant></member> - <member><constant>add_sender</constant> = <constant>EM_MENU_SELECT_ADD_SENDER</constant></member> - <member><constant>mark_junk</constant> = <constant>EM_MENU_SELECT_MARK_JUNK</constant></member> - <member><constant>mark_nojunk</constant> = <constant>EM_MENU_SELECT_MARK_NOJUNK</constant></member> - <member><constant>folder</constant> = <constant>EM_MENU_SELECT_FOLDER</constant></member> - </simplelist> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect3> - </sect2> - </sect1> - - <sect1 id="mail-hooks-config"> - <title>Config Windows and Druids</title> - - <para> - The mail config class is - <interfacename>org.gnome.evolution.mail.config:1.0</interfacename>. - </para> - - &em-configs; - - <sect2> - <title>Mail Config Targets</title> - - <sect3 id="mail-hooks-config-EMConfigTargetAccount"> - <title>Account Target</title> - - <para>The account target is used for configuring accounts, and so - has a pointer to the EAccount being configured. This is a copy - of the actual account object, and is copied to the original once - the data is ready to commit.</para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>account</constant></entry> - </row> - <row> - <entry>Structure</entry> - <entry> - <link - linkend="API-struct--EMConfigTargetAccount">EMConfigTargetAccount</link> - </entry> - </row> - <row> - <entry>Items</entry> - <entry>Define some of the items available and where they fit - in the gui</entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect3> - - <sect3 id="mail-hooks-config-EMConfigTargetPrefs"> - <title>Preferences Target</title> - - <para>The preferences target is used for global preferences. As - such it just contains a pointer to the global configuration store - - a GConfClient.</para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>prefs</constant></entry> - </row> - <row> - <entry>Structure</entry> - <entry> - <link - linkend="API-struct--EMConfigTargetPrefs">EMConfigTargetPrefs</link> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect3> - - <sect3 id="mail-hooks-config-EMConfigTargetFolder"> - <title>Folder Target</title> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>folder</constant></entry> - </row> - <row> - <entry>Structure</entry> - <entry> - <link - linkend="API-struct--EMConfigTargetFolder">EMConfigTargetFolder</link> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect3> - - </sect2> - </sect1> - - <sect1 id="mail-hooks-event"> - <title>Events</title> - - <para> - The mail event class is - <interfacename>org.gnome.evolution.mail.events:1.0</interfacename>. - </para> - - &em-events; - - <sect2> - <title>Mail Event Targets</title> - - <sect3 id="mail-hooks-event-EMEventTargetFolder"> - <title>Folder Target</title> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>folder</constant></entry> - </row> - <row> - <entry>Structure</entry> - <entry> - <link - linkend="API-struct--EMEventTargetFolder">EMEventTargetFolder</link> - </entry> - </row> - <row> - <entry>Qualifiers</entry> - <entry>List qualifiers</entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect3> - </sect2> - </sect1> - - <sect1 id="mail-hooks-format"> - <title>Formatters</title> - - <para> - The mail formatter hook class is - <interfacename>com.novell.evolution.mail.format:1.0</interfacename>. - </para> - - <sect2> - <title>Base Formatter</title> - - <para> - The EMFormat class is the base class for all formatting types. - It should only be used to define compound and complex types which - do not rely on outputting any textual information, or rely on any - screen or print output differences. - </para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>EMFormat</constant></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-format-EMFormatHookTarget">EMFormatHookTarget</link> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect2> - - <sect2> - <title>HTML Formatter</title> - - <para> - The EMFormatHTML class is the base class for most formatting types - which generate HTML output. It renders output to a GtkHTML - object. It uses a fairly complex multi-thread approach to the - formatting to ensure the user-interface is not blocked for - processing. GtkHTML is used in a limited way by this class for - HTML parsing and resolution of embedded objects. Embedded objects - and Widgets may not be used from formatters which hook onto this - entry point. - </para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>EMFormatHTML</constant></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-format-EMFormatHookTarget">EMFormatHookTarget</link> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para> - <emphasis>This section needs a huge amount of - explanation, and/or more detail needs to be added to another - section about the formatter class</emphasis> - </para> - </sect2> - - <sect2> - <title>HTML Display Formatter</title> - - <para> - The EMFormatHTMLDisplay class is a subclass of EMFormatHTML, and is - used as a mail display widget. As such, it has access to all of - the facilities of GtkHTML, such as embedded widgets. Like the - EMFormatHTML class, this uses a complex multi-thread architecture. - </para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>EMFormatHTMLDisplay</constant></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-format-EMFormatHookTarget">EMFormatHookTarget</link> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para> - <emphasis>This section needs a huge amount of - explanation, and/or more detail needs to be added to another - section about the formatter class</emphasis> - </para> - </sect2> - - <sect2> - <title>HTML Print Formatter</title> - - <para> - The EMFormatHTMLPrint class is a subclass of EMFormatHTML, and is - used as a mail printing widget. It cannot access embedded - widgets. For most purposes you would normally only connect to the - EMFormatHTML hook, and generate generic HTML output which could be - printed or shown on-screen if it isn't overriden by the display - formatter. - </para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>EMFormatHTMLPrint</constant></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-format-EMFormatHookTarget">EMFormatHookTarget</link> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para> - <emphasis>This section needs a huge amount of - explanation, and/or more detail needs to be added to another - section about the formatter class</emphasis> - </para> - </sect2> - - <sect2> - <title>Mail Quote Formatter</title> - <para> - The EMFormatQuote class is a subclass of EMFormat, and is - used as generator for quoted mail content and for - inline-forwarding. This formatter converts message objects into - a pure HTML stream, which is not parsed directly, but normally fed - to the message composer. - </para> - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Name</entry> - <entry><constant>EMFormatQuote</constant></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-EMFormatHookTarget">EMFormatHookTarget</link> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect2> - - <sect2 id="mail-hooks-format-EMFormatHookTarget"> - <title>Mail Formatter Targets</title> - - <para>There is only one target for all mail formatters, and it is - implied automatically for all formatter hooks.</para> - - <informaltable> - <tgroup cols="2"> - <colspec colnum="1" colname="field" colwidth="1*"/> - <colspec colnum="2" colname="value" colwidth="4*"/> - <tbody valign="top"> - <row> - <entry>Structure</entry> - <entry> - <link - linkend="API-struct--EMFormatHookTarget">EMFormatHookTarget</link> - </entry> - </row> - <row> - <entry>Flags</entry> - <entry> - <simplelist> - <member><constant>inline</constant> = <constant>EM_FORMAT_HANDLER_INLINE</constant></member> - <member><constant>inline_disposition</constant> = - <constant>EM_FORMAT_HANDLER_INLINE_DISPOSITION</constant></member> - </simplelist> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - - </sect2> - </sect1> - </chapter> - - <chapter id="contacts-hooks"> - <title> - Contacts Hooks - </title> - <para> - Hooks available in the the contacts component. - </para> - - <sect1 id="contacts-hooks-popup"> - <title>Popup menus</title> - - <para> - The contacts popup menu class is - <interfacename>org.gnome.evolution.addressbook.popup:1.0</interfacename>. - </para> - - <!-- TODO: define the entity once it exists - &eab-popups; --> - - <sect2> - <title>Calendar Popup Targets</title> - <para>TBD</para> - </sect2> - </sect1> - - <sect1 id="contacts-hooks-menu"> - <title>Main menus</title> - - <para> - The addressbook menu class is - <interfacename>org.gnome.evolution.addressbook.bonobomenu:1.0</interfacename>. - </para> - - <!-- TODO: define the entity once it exists - &eab-menus; --> - - <sect2> - <title>Contacts Menu Targets</title> - <para>TBD</para> - </sect2> - </sect1> - - <sect1 id="contacts-hooks-config"> - <title>Config Windows and Druids</title> - <para> - The addressbook config class is - <interfacename>org.gnome.evolution.addressbook.config:1.0</interfacename>. - </para> - - <!-- TODO: define the entity once it exists - &eab-configs; --> - - <sect2> - <title>Contacts Config Targets</title> - <para>TBD</para> - </sect2> - </sect1> - - <sect1 id="contacts-hooks-event"> - <title>Events</title> - - <para> - None defined. - </para> - </sect1> - </chapter> - - <chapter id="calendar-hooks"> - <title> - Calendar Hooks - </title> - <para> - Hooks available in the the calendar component. - </para> - - <sect1 id="calendar-hooks-popup"> - <title>Popup menus</title> - - <para> - The calendar popup menu class is - <interfacename>org.gnome.evolution.calendar.popup:1.0</interfacename>. - </para> - - &ecal-popups; - - <sect2> - <title>Calendar Popup Targets</title> - <para>TBD</para> - </sect2> - </sect1> - - <sect1 id="calendar-hooks-menu"> - <title>Main menus</title> - - <para> - The calendar menu class is - <interfacename>org.gnome.evolution.calendar.bonobomenu:1.0</interfacename>. - </para> - - <!-- TODO: define the entity once it exists - &ecal-menus; --> - - <sect2> - <title>Calendar Menu Targets</title> - <para>TBD</para> - </sect2> - </sect1> - - <sect1 id="calendar-hooks-config"> - <title>Config Windows and Druids</title> - <para> - The calendar config class is - <interfacename>org.gnome.evolution.calendar.config:1.0</interfacename>. - </para> - - <!-- TODO: define the entity once it exists - &ecal-configs; --> - - <sect2> - <title>Calendar Config Targets</title> - <para>TBD</para> - </sect2> - </sect1> - - <sect1 id="calendar-hooks-event"> - <title>Events</title> - - <para> - None defined. - </para> - </sect1> - </chapter> - - <chapter id="shell-hooks"> - <title> - Shell Hooks - </title> - - <sect1 id="shell-hooks-menu"> - <title>Main menus</title> - - <para> - The mail menu class is - <interfacename>org.gnome.evolution.shell.bonobomenu:1.0</interfacename>. - </para> - <para> - The plugin callback data will be the target matching the plugin - menu itself, and the callback returns no value. - </para> - &es-menus; - </sect1> - <sect1 id="shell-hooks-event"> - <title>Events</title> - - <para> - The shell event class is - <interfacename>org.gnome.evolution.shell.events:1.0</interfacename>. - </para> - - &es-events; - </sect1> - - </chapter> - - </part> - - <part id="reference"> - <title> - Reference - </title> - <partintro> - <para> - This section of the book is a detailed API reference of the - objects and methods that implement the core plugin system and hooks. - </para> - <para> - It contains the detailed information required for all uses of the - plugin system. That is, implementors - of new hook types, application developers providing hook points, and - plugin developers. - </para> - </partintro> - <chapter id="REF-EPlugin"> - <title> - EPlugin - </title> - <para> - The EPlugin object manages the loading and invocation of physical - plugin definitions and plugin binaries. The base EPlugin class is an - abstract class which loads plugin definitons, resolving hooks, and - provides an api for invoking callbacks. - </para> - <para> - The EPluginLib object is a concrete derived class of EPlugin which - handles loading shared libraries using the GModule interface. - </para> - &e-plugin-reference; - </chapter> - - <chapter> - <title> - EPopup - </title> - <para> - The EPopup object manages a single popup menu. It is used to - application code as a convenience function for building dynamic popup - menus based on a specific context. - </para> - <para> - The EPopupHook object is loaded by - the &EPlugin; system, and is used to provide dynamic extension to the - application context menus. - </para> - &e-popup-reference; - - <!-- this looks like bum here, not sure where else to put it though --> - &em-popup-reference; - </chapter> - - <chapter> - <title> - EMenu - </title> - <para> - The EMenu object manages the menus for a given view or component. It - is used by application code to allow the plugin system an entry point - to current application view. It may also be used by the application as - a convenience function to dynamically alter the menu system based on - user context. - </para> - <para> - The EMenuHook object is loaded by the &EPlugin; system, and is used to - provide dynamic extension to the application menus. - </para> - &e-menu-reference; - </chapter> - - <chapter> - <title> - EConfig - </title> - <para> - The EConfig object manages the building of dynamic configuration pages - to configure specific application objects. The same basic object can - be used to fully drive a wizard-like druid object, or to drive a - note-book of configuration options. It is used by application code to - provide the core controller in a model-view-controller implementation - of a UI window. - </para> - <para> - The EConfigHook object is loaded by the &EPlugin; system, and is used hook - in additional configuration items into configuration windows or druids - dynamically. - </para> - &e-config-reference; - </chapter> - - <chapter> - <title> - EEvent - </title> - <para> - The EEvent object manages broadcast of events for a given component or - application. It is used by application code to provide the plugin - system with an entry point for user and system state events. - </para> - <para> - The EEventHook object is loaded by the &EPlugin; system, and is used hook - event listeners into dynamically loaded event handlers. - </para> - &e-event-reference; - </chapter> - - <chapter> - <title> - EMFormat - </title> - <para> - The EMFormat object drives the formatting of MIME message content for - display, print, and replying. EMFormatHTML is an implementation of - EMFormat which writes its output to a GtkHTML instance. - </para> - <para> - The EMFormatHook object is loaded by the &EPlugin; system, and is used hook - event listeners into dynamically loaded event handlers. - </para> - &em-format-reference; - </chapter> - </part> - -</book> diff --git a/doc/devel/executive-summary/evolution-services.hierarchy b/doc/devel/executive-summary/evolution-services.hierarchy deleted file mode 100644 index 37559d819d..0000000000 --- a/doc/devel/executive-summary/evolution-services.hierarchy +++ /dev/null @@ -1,7 +0,0 @@ -GtkObject - BonoboObject - ExecutiveSummaryComponent - ExecutiveSummaryComponentFactory - Handle to remote Bonobo::Unknown - ExecutiveSummaryComponentFactoryClient - ExecutiveSummaryHtmlView diff --git a/doc/devel/fdl.sgml b/doc/devel/fdl.sgml deleted file mode 100644 index 817adbdbb7..0000000000 --- a/doc/devel/fdl.sgml +++ /dev/null @@ -1,671 +0,0 @@ -<!-- - The GNU Free Documentation License 1.1 in DocBook - Markup by Eric Baudais <baudais@okstate.edu> - Maintained by the GNOME Documentation Project - http://developer.gnome.org/projects/gdp - Version: 1.0.1 - Last Modified: Nov 16, 2000 ---> - -<appendix id="fdl"> - <docinfo> - <releaseinfo> - Version 1.1, March 2000 - </releaseinfo> - <copyright> - <year>2000</year><holder>Free Software Foundation, Inc.</holder> - </copyright> - <legalnotice id="fdl-legalnotice"> - <para> - <address>Free Software Foundation, Inc. <street>59 Temple Place, - Suite 330</street>, <city>Boston</city>, <state>MA</state> - <postcode>02111-1307</postcode> <country>USA</country></address> - Everyone is permitted to copy and distribute verbatim copies of this - license document, but changing it is not allowed. - </para> - </legalnotice> - </docinfo> - <title>GNU Free Documentation License</title> - - <sect1 id="fdl-preamble"> - <title>0. PREAMBLE</title> - <para> - The purpose of this License is to make a manual, textbook, or - other written document <quote>free</quote> in the sense of - freedom: to assure everyone the effective freedom to copy and - redistribute it, with or without modifying it, either - commercially or noncommercially. Secondarily, this License - preserves for the author and publisher a way to get credit for - their work, while not being considered responsible for - modifications made by others. - </para> - - <para> - This License is a kind of <quote>copyleft</quote>, which means - that derivative works of the document must themselves be free in - the same sense. It complements the GNU General Public License, - which is a copyleft license designed for free software. - </para> - - <para> - We have designed this License in order to use it for manuals for - free software, because free software needs free documentation: a - free program should come with manuals providing the same - freedoms that the software does. But this License is not limited - to software manuals; it can be used for any textual work, - regardless of subject matter or whether it is published as a - printed book. We recommend this License principally for works - whose purpose is instruction or reference. - </para> - </sect1> - <sect1 id="fdl-section1"> - <title>1. APPLICABILITY AND DEFINITIONS</title> - <para id="fdl-document"> - This License applies to any manual or other work that contains a - notice placed by the copyright holder saying it can be - distributed under the terms of this License. The - <quote>Document</quote>, below, refers to any such manual or - work. Any member of the public is a licensee, and is addressed - as <quote>you</quote>. - </para> - - <para id="fdl-modified"> - A <quote>Modified Version</quote> of the Document means any work - containing the Document or a portion of it, either copied - verbatim, or with modifications and/or translated into another - language. - </para> - - <para id="fdl-secondary"> - A <quote>Secondary Section</quote> is a named appendix or a - front-matter section of the <link - linkend="fdl-document">Document</link> that deals exclusively - with the relationship of the publishers or authors of the - Document to the Document's overall subject (or to related - matters) and contains nothing that could fall directly within - that overall subject. (For example, if the Document is in part a - textbook of mathematics, a Secondary Section may not explain any - mathematics.) The relationship could be a matter of historical - connection with the subject or with related matters, or of - legal, commercial, philosophical, ethical or political position - regarding them. - </para> - - <para id="fdl-invariant"> - The <quote>Invariant Sections</quote> are certain <link - linkend="fdl-secondary"> Secondary Sections</link> whose titles - are designated, as being those of Invariant Sections, in the - notice that says that the <link - linkend="fdl-document">Document</link> is released under this - License. - </para> - - <para id="fdl-cover-texts"> - The <quote>Cover Texts</quote> are certain short passages of - text that are listed, as Front-Cover Texts or Back-Cover Texts, - in the notice that says that the <link - linkend="fdl-document">Document</link> is released under this - License. - </para> - - <para id="fdl-transparent"> - A <quote>Transparent</quote> copy of the <link - linkend="fdl-document"> Document</link> means a machine-readable - copy, represented in a format whose specification is available - to the general public, whose contents can be viewed and edited - directly and straightforwardly with generic text editors or (for - images composed of pixels) generic paint programs or (for - drawings) some widely available drawing editor, and that is - suitable for input to text formatters or for automatic - translation to a variety of formats suitable for input to text - formatters. A copy made in an otherwise Transparent file format - whose markup has been designed to thwart or discourage - subsequent modification by readers is not Transparent. A copy - that is not <quote>Transparent</quote> is called - <quote>Opaque</quote>. - </para> - - <para> - Examples of suitable formats for Transparent copies include - plain ASCII without markup, Texinfo input format, LaTeX input - format, SGML or XML using a publicly available DTD, and - standard-conforming simple HTML designed for human - modification. Opaque formats include PostScript, PDF, - proprietary formats that can be read and edited only by - proprietary word processors, SGML or XML for which the DTD - and/or processing tools are not generally available, and the - machine-generated HTML produced by some word processors for - output purposes only. - </para> - - <para id="fdl-title-page"> - The <quote>Title Page</quote> means, for a printed book, the - title page itself, plus such following pages as are needed to - hold, legibly, the material this License requires to appear in - the title page. For works in formats which do not have any title - page as such, <quote>Title Page</quote> means the text near the - most prominent appearance of the work's title, preceding the - beginning of the body of the text. - </para> - </sect1> - - <sect1 id="fdl-section2"> - <title>2. VERBATIM COPYING</title> - <para> - You may copy and distribute the <link - linkend="fdl-document">Document</link> in any medium, either - commercially or noncommercially, provided that this License, the - copyright notices, and the license notice saying this License - applies to the Document are reproduced in all copies, and that - you add no other conditions whatsoever to those of this - License. You may not use technical measures to obstruct or - control the reading or further copying of the copies you make or - distribute. However, you may accept compensation in exchange for - copies. If you distribute a large enough number of copies you - must also follow the conditions in <link - linkend="fdl-section3">section 3</link>. - </para> - - <para> - You may also lend copies, under the same conditions stated - above, and you may publicly display copies. - </para> - </sect1> - - <sect1 id="fdl-section3"> - <title>3. COPYING IN QUANTITY</title> - <para> - If you publish printed copies of the <link - linkend="fdl-document">Document</link> numbering more than 100, - and the Document's license notice requires <link - linkend="fdl-cover-texts">Cover Texts</link>, you must enclose - the copies in covers that carry, clearly and legibly, all these - Cover Texts: Front-Cover Texts on the front cover, and - Back-Cover Texts on the back cover. Both covers must also - clearly and legibly identify you as the publisher of these - copies. The front cover must present the full title with all - words of the title equally prominent and visible. You may add - other material on the covers in addition. Copying with changes - limited to the covers, as long as they preserve the title of the - <link linkend="fdl-document">Document</link> and satisfy these - conditions, can be treated as verbatim copying in other - respects. - </para> - - <para> - If the required texts for either cover are too voluminous to fit - legibly, you should put the first ones listed (as many as fit - reasonably) on the actual cover, and continue the rest onto - adjacent pages. - </para> - - <para> - If you publish or distribute <link - linkend="fdl-transparent">Opaque</link> copies of the <link - linkend="fdl-document">Document</link> numbering more than 100, - you must either include a machine-readable <link - linkend="fdl-transparent">Transparent</link> copy along with - each Opaque copy, or state in or with each Opaque copy a - publicly-accessible computer-network location containing a - complete Transparent copy of the Document, free of added - material, which the general network-using public has access to - download anonymously at no charge using public-standard network - protocols. If you use the latter option, you must take - reasonably prudent steps, when you begin distribution of Opaque - copies in quantity, to ensure that this Transparent copy will - remain thus accessible at the stated location until at least one - year after the last time you distribute an Opaque copy (directly - or through your agents or retailers) of that edition to the - public. - </para> - - <para> - It is requested, but not required, that you contact the authors - of the <link linkend="fdl-document">Document</link> well before - redistributing any large number of copies, to give them a chance - to provide you with an updated version of the Document. - </para> - </sect1> - - <sect1 id="fdl-section4"> - <title>4. MODIFICATIONS</title> - <para> - You may copy and distribute a <link - linkend="fdl-modified">Modified Version</link> of the <link - linkend="fdl-document">Document</link> under the conditions of - sections <link linkend="fdl-section2">2</link> and <link - linkend="fdl-section3">3</link> above, provided that you release - the Modified Version under precisely this License, with the - Modified Version filling the role of the Document, thus - licensing distribution and modification of the Modified Version - to whoever possesses a copy of it. In addition, you must do - these things in the Modified Version: - </para> - - <itemizedlist mark="opencircle"> - <listitem> - <formalpara> - <title>A</title> - <para> - Use in the <link linkend="fdl-title-page">Title - Page</link> (and on the covers, if any) a title distinct - from that of the <link - linkend="fdl-document">Document</link>, and from those of - previous versions (which should, if there were any, be - listed in the History section of the Document). You may - use the same title as a previous version if the original - publisher of that version gives permission. - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>B</title> - <para> - List on the <link linkend="fdl-title-page">Title - Page</link>, as authors, one or more persons or entities - responsible for authorship of the modifications in the - <link linkend="fdl-modified">Modified Version</link>, - together with at least five of the principal authors of - the <link linkend="fdl-document">Document</link> (all of - its principal authors, if it has less than five). - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>C</title> - <para> - State on the <link linkend="fdl-title-page">Title - Page</link> the name of the publisher of the <link - linkend="fdl-modified">Modified Version</link>, as the - publisher. - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>D</title> - <para> - Preserve all the copyright notices of the <link - linkend="fdl-document">Document</link>. - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>E</title> - <para> - Add an appropriate copyright notice for your modifications - adjacent to the other copyright notices. - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>F</title> - <para> - Include, immediately after the copyright notices, a - license notice giving the public permission to use the - <link linkend="fdl-modified">Modified Version</link> under - the terms of this License, in the form shown in the - Addendum below. - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>G</title> - <para> - Preserve in that license notice the full lists of <link - linkend="fdl-invariant"> Invariant Sections</link> and - required <link linkend="fdl-cover-texts">Cover - Texts</link> given in the <link - linkend="fdl-document">Document's</link> license notice. - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>H</title> - <para> - Include an unaltered copy of this License. - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>I</title> - <para> - Preserve the section entitled <quote>History</quote>, and - its title, and add to it an item stating at least the - title, year, new authors, and publisher of the <link - linkend="fdl-modified">Modified Version </link>as given on - the <link linkend="fdl-title-page">Title Page</link>. If - there is no section entitled <quote>History</quote> in the - <link linkend="fdl-document">Document</link>, create one - stating the title, year, authors, and publisher of the - Document as given on its Title Page, then add an item - describing the Modified Version as stated in the previous - sentence. - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>J</title> - <para> - Preserve the network location, if any, given in the <link - linkend="fdl-document">Document</link> for public access - to a <link linkend="fdl-transparent">Transparent</link> - copy of the Document, and likewise the network locations - given in the Document for previous versions it was based - on. These may be placed in the <quote>History</quote> - section. You may omit a network location for a work that - was published at least four years before the Document - itself, or if the original publisher of the version it - refers to gives permission. - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>K</title> - <para> - In any section entitled <quote>Acknowledgements</quote> or - <quote>Dedications</quote>, preserve the section's title, - and preserve in the section all the substance and tone of - each of the contributor acknowledgements and/or - dedications given therein. - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>L</title> - <para> - Preserve all the <link linkend="fdl-invariant">Invariant - Sections</link> of the <link - linkend="fdl-document">Document</link>, unaltered in their - text and in their titles. Section numbers or the - equivalent are not considered part of the section titles. - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>M</title> - <para> - Delete any section entitled - <quote>Endorsements</quote>. Such a section may not be - included in the <link linkend="fdl-modified">Modified - Version</link>. - </para> - </formalpara> - </listitem> - - <listitem> - <formalpara> - <title>N</title> - <para> - Do not retitle any existing section as - <quote>Endorsements</quote> or to conflict in title with - any <link linkend="fdl-invariant">Invariant - Section</link>. - </para> - </formalpara> - </listitem> - </itemizedlist> - - <para> - If the <link linkend="fdl-modified">Modified Version</link> - includes new front-matter sections or appendices that qualify as - <link linkend="fdl-secondary">Secondary Sections</link> and - contain no material copied from the Document, you may at your - option designate some or all of these sections as invariant. To - do this, add their titles to the list of <link - linkend="fdl-invariant">Invariant Sections</link> in the - Modified Version's license notice. These titles must be - distinct from any other section titles. - </para> - - <para> - You may add a section entitled <quote>Endorsements</quote>, - provided it contains nothing but endorsements of your <link - linkend="fdl-modified">Modified Version</link> by various - parties--for example, statements of peer review or that the text - has been approved by an organization as the authoritative - definition of a standard. - </para> - - <para> - You may add a passage of up to five words as a <link - linkend="fdl-cover-texts">Front-Cover Text</link>, and a passage - of up to 25 words as a <link - linkend="fdl-cover-texts">Back-Cover Text</link>, to the end of - the list of <link linkend="fdl-cover-texts">Cover Texts</link> - in the <link linkend="fdl-modified">Modified Version</link>. - Only one passage of Front-Cover Text and one of Back-Cover Text - may be added by (or through arrangements made by) any one - entity. If the <link linkend="fdl-document">Document</link> - already includes a cover text for the same cover, previously - added by you or by arrangement made by the same entity you are - acting on behalf of, you may not add another; but you may - replace the old one, on explicit permission from the previous - publisher that added the old one. - </para> - - <para> - The author(s) and publisher(s) of the <link - linkend="fdl-document">Document</link> do not by this License - give permission to use their names for publicity for or to - assert or imply endorsement of any <link - linkend="fdl-modified">Modified Version </link>. - </para> - </sect1> - - <sect1 id="fdl-section5"> - <title>5. COMBINING DOCUMENTS</title> - <para> - You may combine the <link linkend="fdl-document">Document</link> - with other documents released under this License, under the - terms defined in <link linkend="fdl-section4">section 4</link> - above for modified versions, provided that you include in the - combination all of the <link linkend="fdl-invariant">Invariant - Sections</link> of all of the original documents, unmodified, - and list them all as Invariant Sections of your combined work in - its license notice. - </para> - - <para> - The combined work need only contain one copy of this License, - and multiple identical <link linkend="fdl-invariant">Invariant - Sections</link> may be replaced with a single copy. If there are - multiple Invariant Sections with the same name but different - contents, make the title of each such section unique by adding - at the end of it, in parentheses, the name of the original - author or publisher of that section if known, or else a unique - number. Make the same adjustment to the section titles in the - list of Invariant Sections in the license notice of the combined - work. - </para> - - <para> - In the combination, you must combine any sections entitled - <quote>History</quote> in the various original documents, - forming one section entitled <quote>History</quote>; likewise - combine any sections entitled <quote>Acknowledgements</quote>, - and any sections entitled <quote>Dedications</quote>. You must - delete all sections entitled <quote>Endorsements.</quote> - </para> - </sect1> - - <sect1 id="fdl-section6"> - <title>6. COLLECTIONS OF DOCUMENTS</title> - <para> - You may make a collection consisting of the <link - linkend="fdl-document">Document</link> and other documents - released under this License, and replace the individual copies - of this License in the various documents with a single copy that - is included in the collection, provided that you follow the - rules of this License for verbatim copying of each of the - documents in all other respects. - </para> - - <para> - You may extract a single document from such a collection, and - dispbibute it individually under this License, provided you - insert a copy of this License into the extracted document, and - follow this License in all other respects regarding verbatim - copying of that document. - </para> - </sect1> - - <sect1 id="fdl-section7"> - <title>7. AGGREGATION WITH INDEPENDENT WORKS</title> - <para> - A compilation of the <link - linkend="fdl-document">Document</link> or its derivatives with - other separate and independent documents or works, in or on a - volume of a storage or distribution medium, does not as a whole - count as a <link linkend="fdl-modified">Modified Version</link> - of the Document, provided no compilation copyright is claimed - for the compilation. Such a compilation is called an - <quote>aggregate</quote>, and this License does not apply to the - other self-contained works thus compiled with the Document , on - account of their being thus compiled, if they are not themselves - derivative works of the Document. If the <link - linkend="fdl-cover-texts">Cover Text</link> requirement of <link - linkend="fdl-section3">section 3</link> is applicable to these - copies of the Document, then if the Document is less than one - quarter of the entire aggregate, the Document's Cover Texts may - be placed on covers that surround only the Document within the - aggregate. Otherwise they must appear on covers around the whole - aggregate. - </para> - </sect1> - - <sect1 id="fdl-section8"> - <title>8. TRANSLATION</title> - <para> - Translation is considered a kind of modification, so you may - distribute translations of the <link - linkend="fdl-document">Document</link> under the terms of <link - linkend="fdl-section4">section 4</link>. Replacing <link - linkend="fdl-invariant"> Invariant Sections</link> with - translations requires special permission from their copyright - holders, but you may include translations of some or all - Invariant Sections in addition to the original versions of these - Invariant Sections. You may include a translation of this - License provided that you also include the original English - version of this License. In case of a disagreement between the - translation and the original English version of this License, - the original English version will prevail. - </para> - </sect1> - - <sect1 id="fdl-section9"> - <title>9. TERMINATION</title> - <para> - You may not copy, modify, sublicense, or distribute the <link - linkend="fdl-document">Document</link> except as expressly - provided for under this License. Any other attempt to copy, - modify, sublicense or distribute the Document is void, and will - automatically terminate your rights under this License. However, - parties who have received copies, or rights, from you under this - License will not have their licenses terminated so long as such - parties remain in full compliance. - </para> - </sect1> - - <sect1 id="fdl-section10"> - <title>10. FUTURE REVISIONS OF THIS LICENSE</title> - <para> - The <ulink type="http" - url="http://www.gnu.org/fsf/fsf.html">Free Software - Foundation</ulink> may publish new, revised versions of the GNU - Free Documentation License from time to time. Such new versions - will be similar in spirit to the present version, but may differ - in detail to address new problems or concerns. See <ulink - type="http" - url="http://www.gnu.org/copyleft">http://www.gnu.org/copyleft/</ulink>. - </para> - - <para> - Each version of the License is given a distinguishing version - number. If the <link linkend="fdl-document">Document</link> - specifies that a particular numbered version of this License - <quote>or any later version</quote> applies to it, you have the - option of following the terms and conditions either of that - specified version or of any later version that has been - published (not as a draft) by the Free Software Foundation. If - the Document does not specify a version number of this License, - you may choose any version ever published (not as a draft) by - the Free Software Foundation. - </para> - </sect1> - - <sect1 id="fdl-using"> - <title>Addendum</title> - <para> - To use this License in a document you have written, include a copy of - the License in the document and put the following copyright and - license notices just after the title page: - </para> - - <blockquote> - <para> - Copyright © YEAR YOUR NAME. - </para> - <para> - Permission is granted to copy, distribute and/or modify this - document under the terms of the GNU Free Documentation - License, Version 1.1 or any later version published by the - Free Software Foundation; with the <link - linkend="fdl-invariant">Invariant Sections</link> being LIST - THEIR TITLES, with the <link - linkend="fdl-cover-texts">Front-Cover Texts</link> being LIST, - and with the <link linkend="fdl-cover-texts">Back-Cover - Texts</link> being LIST. A copy of the license is included in - the section entitled <quote>GNU Free Documentation - License</quote>. - </para> - </blockquote> - - <para> - If you have no <link linkend="fdl-invariant">Invariant - Sections</link>, write <quote>with no Invariant Sections</quote> - instead of saying which ones are invariant. If you have no - <link linkend="fdl-cover-texts">Front-Cover Texts</link>, write - <quote>no Front-Cover Texts</quote> instead of - <quote>Front-Cover Texts being LIST</quote>; likewise for <link - linkend="fdl-cover-texts">Back-Cover Texts</link>. - </para> - - <para> - If your document contains nontrivial examples of program code, - we recommend releasing these examples in parallel under your - choice of free software license, such as the <ulink type="http" - url="http://www.gnu.org/copyleft/gpl.html"> GNU General Public - License</ulink>, to permit their use in free software. - </para> - </sect1> -</appendix> - - - - - - diff --git a/doc/devel/images/Makefile b/doc/devel/images/Makefile deleted file mode 100644 index bef9f8bf62..0000000000 --- a/doc/devel/images/Makefile +++ /dev/null @@ -1,21 +0,0 @@ - -# this is only a temporary makefile - -# you need ps2eps, groff, pnmutils, and ghostscript installed - -PICS=e-config-flow.pic e-popup-merge-1.pic e-popup-merge-2.pic -EPS=$(PICS:.pic=.eps) -PNG=$(PICS:.pic=.png) - -all: $(PNG) - -%.eps: %.pic - groff -p $^ | ps2eps -f -l > $@ - -%.png: %.pic - groff -p $^ \ - | gs -q -dSAFER -dNOPAUSE -dBATCH -r180 -sDEVICE=pnmraw -sOutputFile=- - -c quit \ - | pnmcrop \ - | pnmscale 0.5 \ - | pnmtopng > $@ - diff --git a/doc/devel/images/e-config-build-1.png b/doc/devel/images/e-config-build-1.png Binary files differdeleted file mode 100644 index a18f8ab503..0000000000 --- a/doc/devel/images/e-config-build-1.png +++ /dev/null diff --git a/doc/devel/images/e-config-build-2.png b/doc/devel/images/e-config-build-2.png Binary files differdeleted file mode 100644 index 455a21728f..0000000000 --- a/doc/devel/images/e-config-build-2.png +++ /dev/null diff --git a/doc/devel/images/e-config-build-3.png b/doc/devel/images/e-config-build-3.png Binary files differdeleted file mode 100644 index 546210793e..0000000000 --- a/doc/devel/images/e-config-build-3.png +++ /dev/null diff --git a/doc/devel/images/e-config-flow.pic b/doc/devel/images/e-config-flow.pic deleted file mode 100644 index a75a8b6087..0000000000 --- a/doc/devel/images/e-config-flow.pic +++ /dev/null @@ -1,36 +0,0 @@ - -.PS 5 -space=0.7 -[ - Editor: ellipse "Editor" - Pages: box "Pages" at last ellipse + (0,-space) - Sections: box "Sections" at last box + (space/4, -space/2) fill 0 - Items: box "Items" at last box + (space/4, -space/2) fill 0 - line <-> from Editor.s to Pages.n -] -Manager: box dashed ht last [].ht+0.2 wid last[].wid+.2 at last [] -right; move; move -[ - EConfig: ellipse "EConfig" - EMConfig: ellipse "EMConfig" at last ellipse + (0,-space) -] -Config: box dashed ht last [].ht+0.2 wid last[].wid+.2 at last [] - -EMTargetAccount: ellipse "Account" "Target" at Config.e + (1.5*space, 0) -Druid: ellipse "Druid" at Config.s + (0,-1.5*space) -EAccount: ellipse "EAccount" at Config.se + (1.5*space,-1.5*space) - -line <-> from Config.s to Druid.n " next, prepare" ljust "create, enable " rjust -line -> from EAccount.n to EMTargetAccount.s " initialise" ljust " change" ljust - -line <-> from EAccount.w to Druid.e "initialise" "changes" -line <-> from Config.e to EMTargetAccount.w "create" "changed" - -line <-> from Manager.e to Config.w "create" "check" "commit" "abort" -spline <-> from Manager.s \ - to (Manager.s.x,Druid.s.y) \ - to (Manager.s.x+space/2,Druid.s.y-space/2) \ - then to EAccount.s + (-space/2,-space/2) \ - then to EAccount.s -.PE - diff --git a/doc/devel/images/e-popup-merge-1.pic b/doc/devel/images/e-popup-merge-1.pic deleted file mode 100644 index 1baa83a793..0000000000 --- a/doc/devel/images/e-popup-merge-1.pic +++ /dev/null @@ -1,61 +0,0 @@ - -.PS 5 -space=0.7 -down -define item { - [ right - box ht 0.25 wid 0 $1 ljust invis - box ht 0.25 wid 3 "" invis ] - [ right - box ht 0.25 wid 0 $3 ljust invis - box ht 0.25 wid 3 $2 ljust invis ] - box ht 0.5 wid 3 at last [].n -} - -define link { - line -> from $1.e + (0.1,0) to $2.w - (0.1,0) -} - -define title { - box ht 0.5 wid 3 $1 invis -} - -A: [ - title("Core Menu") - - Copy: item("Copy", "many", "00.copy") - Paste: item("Paste", "", "01.paste") - Bar1: item("-----", "one", "20.") - Open: item("Open", "one", "21.open") - Save: item("Save...", "one", "22.save") - Bar2: item("-----", "", "40.") - Read: item("Mark as Read", "mark_read", "41.markread") - Unread: item("Mark as Unread", "mark_unread", "42.markunread") -] - -move -B: [ - title("Additional Items") - - ReplyList: item("Reply To List", "one", "02.replylist") - Forward: item("Forward", "any", "03.forward") -] - -C: [ - title("Merged Menu") - - Copy: item("Copy", "", "00.copy") - Paste: item("Paste", "", "01.paste") - Forward: item("Forward", "", "03.forward") - Bar2: item("-----", "", "40.") - Unread: item("Mark as Unread", "", "42.markunread") -] with .nw at A.ne + ( 2,-1) - -link(A.Copy, C.Copy) -link(A.Paste, C.Paste) -link(B.Forward, C.Forward) -link(A.Bar2, C.Bar2) -link(A.Unread, C.Unread) - -.PE - diff --git a/doc/devel/images/e-popup-merge-2.pic b/doc/devel/images/e-popup-merge-2.pic deleted file mode 100644 index 277d451517..0000000000 --- a/doc/devel/images/e-popup-merge-2.pic +++ /dev/null @@ -1,67 +0,0 @@ - -.PS 5 -space=0.7 -down -define item { - [ right - box ht 0.25 wid 0 $1 ljust invis - box ht 0.25 wid 3 "" invis ] - [ right - box ht 0.25 wid 0 $3 ljust invis - box ht 0.25 wid 3 $2 ljust invis ] - box ht 0.5 wid 3 at last [].n -} - -define link { - line -> from $1.e + (0.1,0) to $2.w - (0.1,0) -} - -define title { - box ht 0.5 wid 3 $1 invis -} - -A: [ - title("Core Menu") - - Copy: item("Copy", "many", "00.copy") - Paste: item("Paste", "", "01.paste") - Bar1: item("-----", "one", "20.") - Open: item("Open", "one", "21.open") - Save: item("Save...", "one", "22.save") - Bar2: item("-----", "", "40.") - Read: item("Mark as Read", "mark_read", "41.markread") - Unread: item("Mark as Unread", "mark_unread", "42.markunread") -] - -move -B: [ - title("Additional Items") - - ReplyList: item("Reply To List", "one", "02.replylist") - Forward: item("Forward", "any", "03.forward") -] - -C: [ - title("Merged Menu") - - Paste: item("Paste", "", "01.paste") - ReplyList: item("Reply To List", "", "02.replylist") - Forward: item("Forward", "", "03.forward") - Bar1: item("-----", "", "20.") - Open: item("Open", "", "21.open"); - Save: item("Save...", "", "22.save") - Bar2: item("-----", "", "40.") - Read: item("Mark as Read", "", "41.markread") -] with .nw at A.ne + ( 2,-1) - -link(A.Paste, C.Paste) -link(B.ReplyList, C.ReplyList) -link(B.Forward, C.Forward) -link(A.Bar1, C.Bar1) -link(A.Open, C.Open) -link(A.Save, C.Save) -link(A.Bar2, C.Bar2) -link(A.Read, C.Read) - -.PE - diff --git a/doc/devel/importer/.cvsignore b/doc/devel/importer/.cvsignore deleted file mode 100644 index 439d6641ff..0000000000 --- a/doc/devel/importer/.cvsignore +++ /dev/null @@ -1,10 +0,0 @@ -sgml -Makefile -Makefile.in -*-decl.txt -*-decl-list.txt -*-unused.txt -*.hierarchy -*.signals -*.stamp -*-scan.c diff --git a/doc/devel/importer/Makefile.am b/doc/devel/importer/Makefile.am deleted file mode 100644 index 8b5343677a..0000000000 --- a/doc/devel/importer/Makefile.am +++ /dev/null @@ -1,195 +0,0 @@ -## Process this file with automake to produce Makefile.in - -# The name of the module, e.g. 'glib'. -DOC_MODULE=evolution-shell-importer - -# The top-level SGML file. Change it if you want. -DOC_MAIN_SGML_FILE=$(DOC_MODULE)-docs.sgml - -# The directory containing the source code. Relative to $(srcdir). -# gtk-doc will search all .c & .h files beneath here for inline comments -# documenting functions and macros. -DOC_SOURCE_DIR=$(EVOLUTION_DIR)/shell/importer - -# Extra options to supply to gtkdoc-scan. -SCAN_OPTIONS= - -# Extra options to supply to gtkdoc-mkdb. -MKDB_OPTIONS= - -# Extra options to supply to gtkdoc-fixref. -FIXXREF_OPTIONS= - -# Used for dependencies. -HFILE_GLOB= \ - $(top_srcdir)/shell/importer/evolution-importer.h \ - $(top_srcdir)/shell/importer/evolution-importer-client.h - -CFILE_GLOB= \ - $(top_srcdir)/shell/importer/evolution-importer.c \ - $(top_srcdir)/shell/importer/evolution-importer-client.c - -# Header files to ignore when scanning. -IGNORE_HFILES= \ - GNOME_Evolution_Importer.h \ - importer.h - -# Images to copy into HTML directory. -HTML_IMAGES = - -# Extra SGML files that are included by $(DOC_MAIN_SGML_FILE). -content_files = - -# Other files to distribute. -extra_files = - -# CFLAGS and LDFLAGS for compiling scan program. Only needed if your app/lib -# contains GtkObjects/GObjects and you want to document signals and properties. -GTKDOC_CFLAGS = \ - -I$(top_srcdir)/shell/importer \ - -I$(top_srcdir)/shell \ - -I$(top_srcdir) \ - -I$(top_builddir) \ - $(BONOBO_VFS_GNOME_CFLAGS) - -GTKDOC_LIBS = \ - $(BONOBO_VFS_GNOME_LIBS) \ - $(top_builddir)/shell/importer/.libs/libevolution-importer.so - -GTKDOC_CC=$(LIBTOOL) --mode=compile $(CC) -GTKDOC_LD=$(LIBTOOL) --mode=link $(CC) - -# If you need to override some of the declarations, place them in this file -# and uncomment this line. -#DOC_OVERRIDES = $(DOC_MODULE)-overrides.txt -DOC_OVERRIDES = - -########################################################################### -# Everything below here is generic and you shouldn't need to change it. -########################################################################### - -TARGET_DIR=$(HTML_DIR)/$(DOC_MODULE) - -EXTRA_DIST = \ - $(content_files) \ - $(extra_files) \ - $(HTML_IMAGES) \ - $(DOC_MAIN_SGML_FILE) \ - $(DOC_MODULE).types \ - $(DOC_MODULE)-sections.txt \ - $(DOC_OVERRIDES) - -DOC_STAMPS=scan-build.stamp tmpl-build.stamp sgml-build.stamp html-build.stamp \ - $(srcdir)/tmpl.stamp $(srcdir)/sgml.stamp $(srcdir)/html.stamp - -SCANOBJ_FILES = \ - $(DOC_MODULE).args \ - $(DOC_MODULE).hierarchy \ - $(DOC_MODULE).signals - -if ENABLE_GTK_DOC -#all-local: html-build.stamp -all-local: sgml-build.stamp - -#### scan #### - -scan-build.stamp: $(HFILE_GLOB) - @echo '*** Scanning header files ***' - if grep -l '^..*$$' $(srcdir)/$(DOC_MODULE).types > /dev/null ; then \ - CC="$(GTKDOC_CC)" LD="$(GTKDOC_LD)" CFLAGS="$(GTKDOC_CFLAGS)" LDFLAGS="$(GTKDOC_LIBS)" gtkdoc-scanobj --module=$(DOC_MODULE) --output-dir=$(srcdir) ; \ - else \ - cd $(srcdir) ; \ - for i in $(SCANOBJ_FILES) ; do \ - test -f $$i || touch $$i ; \ - done \ - fi - cd $(srcdir) && \ - gtkdoc-scan --module=$(DOC_MODULE) --source-dir=$(DOC_SOURCE_DIR) --ignore-headers="$(IGNORE_HFILES)" $(SCAN_OPTIONS) $(EXTRA_HFILES) - touch scan-build.stamp - -$(DOC_MODULE)-decl.txt $(SCANOBJ_FILES): scan-build.stamp - @true - -#### templates #### - -tmpl-build.stamp: $(DOC_MODULE)-decl.txt $(SCANOBJ_FILES) $(DOC_MODULE)-sections.txt $(DOC_OVERRIDES) - @echo '*** Rebuilding template files ***' - cd $(srcdir) && gtkdoc-mktmpl --module=$(DOC_MODULE) - touch tmpl-build.stamp - -tmpl.stamp: tmpl-build.stamp - @true - -#### sgml #### - -sgml-build.stamp: tmpl.stamp $(CFILE_GLOB) $(srcdir)/tmpl/*.sgml - @echo '*** Building SGML ***' - cd $(srcdir) && \ - gtkdoc-mkdb --module=$(DOC_MODULE) --source-dir=$(DOC_SOURCE_DIR) --main-sgml-file=$(DOC_MAIN_SGML_FILE) $(MKDB_OPTIONS) - touch sgml-build.stamp - -sgml.stamp: sgml-build.stamp - @true - -#### html #### - -html-build.stamp: sgml.stamp $(DOC_MAIN_SGML_FILE) $(content_files) - @echo '*** Building HTML ***' - test -d $(srcdir)/html || mkdir $(srcdir)/html - cd $(srcdir)/html && gtkdoc-mkhtml $(DOC_MODULE) ../$(DOC_MAIN_SGML_FILE) - test "x$(HTML_IMAGES)" = "x" || ( cd $(srcdir) && cp $(HTML_IMAGES) html ) - @echo '-- Fixing Crossreferences' - cd $(srcdir) && gtkdoc-fixxref --module-dir=html --html-dir=$(HTML_DIR) $(FIXXREF_OPTIONS) - touch html-build.stamp -endif - -############## - -clean-local: - rm -f *~ *.bak $(SCANOBJ_FILES) *-unused.txt $(DOC_STAMPS) - -maintainer-clean-local: clean - cd $(srcdir) && rm -rf sgml html $(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt - -install-data-local: - $(mkinstalldirs) $(DESTDIR)$(TARGET_DIR) - (installfiles=`echo $(srcdir)/html/*.html`; \ - if test "$$installfiles" = '$(srcdir)/html/*.html'; \ - then echo '-- Nothing to install' ; \ - else \ - for i in $$installfiles; do \ - echo '-- Installing '$$i ; \ - $(INSTALL_DATA) $$i $(DESTDIR)$(TARGET_DIR); \ - done; \ - echo '-- Installing $(srcdir)/html/index.sgml' ; \ - $(INSTALL_DATA) $(srcdir)/html/index.sgml $(DESTDIR)$(TARGET_DIR); \ - fi) - -# -# Require gtk-doc when making dist -# -if ENABLE_GTK_DOC -dist-check-gtkdoc: -else -dist-check-gtkdoc: - @echo "*** gtk-doc must be installed and enabled in order to make dist" - @false -endif - -dist-hook: dist-check-gtkdoc dist-hook-local - mkdir $(distdir)/tmpl - mkdir $(distdir)/sgml - mkdir $(distdir)/html - -cp $(srcdir)/tmpl/*.sgml $(distdir)/tmpl - -cp $(srcdir)/sgml/*.sgml $(distdir)/sgml - -cp $(srcdir)/html/index.sgml $(distdir)/html - -cp $(srcdir)/html/*.html $(srcdir)/html/*.css $(distdir)/html - - images=$(HTML_IMAGES) ; \ - for i in $$images ; do \ - cp $(srcdir)/$$i $(distdir)/html ; \ - done - -.PHONY : dist-hook-local - - diff --git a/doc/devel/importer/evolution-shell-importer-sections.txt b/doc/devel/importer/evolution-shell-importer-sections.txt deleted file mode 100644 index e2474f6375..0000000000 --- a/doc/devel/importer/evolution-shell-importer-sections.txt +++ /dev/null @@ -1,79 +0,0 @@ -<INCLUDE>evolution-importer.h</INCLUDE> - -<SECTION> -<FILE>evolution-importer</FILE> -EVOLUTION_IMPORTER -<TITLE>EvolutionImporter</TITLE> - -EvolutionImporterSupportFormatFn -EvolutionImporterLoadFileFn -EvolutionImporterProcessItemFn -EvolutionImporterGetErrorFn - -EvolutionImporterResult - -evolution_importer_new - -<SUBSECTION Standard> -EVOLUTION_TYPE_IMPORTER -EVOLUTION_IMPORTER -EVOLUTION_IS_IMPORTER -EVOLUTION_IMPORTER_CLASS -EVOLUTION_IS_IMPORTER_CLASS -evolution_importer_get_type - -<SUBSECTION Private> -EvolutionImporter -EvolutionImporterPrivate - -</SECTION> - -<INCLUDE>evolution-importer-listener.h</INCLUDE> -<SECTION> -<FILE>evolution-importer-listener</FILE> -EVOLUTION_IMPORTER_LISTENER -<TITLE>EvolutionImporterListener</TITLE> - -EvolutionImporterListenerCallback - -evolution_importer_listener_new - -<SUBSECTION Standard> -EVOLUTION_TYPE_IMPORTER_LISTENER -EVOLUTION_IMPORTER_LISTENER -EVOLUTION_IMPORTER_LISTENER_CLASS -EVOLUTION_IS_IMPORTER_LISTENER -EVOLUTION_IS_IMPORTER_LISTENER_CLASS -evolution_importer_listener_get_type - -<SUBSECTION Private> -EvolutionImporterListener -EvolutionImporterListenerPrivate - -</SECTION> - -<INCLUDE>evolution-importer-client.h</INCLUDE> -<SECTION> -<FILE>evolution-importer-client</FILE> -EVOLUTION_IMPORTER_CLIENT -<TITLE>EvolutionImporterClient</TITLE> - -evolution_importer_client_new -evolution_importer_client_new_from_id -evolution_importer_client_support_format -evolution_importer_client_load_file -evolution_importer_client_process_item -evolution_importer_client_get_error - -<SUBSECTION Standard> -EVOLUTION_TYPE_IMPORTER_CLIENT -EVOLUTION_IMPORTER_CLIENT -EVOLUTION_IMPORTER_CLIENT_CLASS -EVOLUTION_IS_IMPORTER_CLIENT -EVOLUTION_IS_IMPORTER_CLIENT_CLASS -evolution_importer_client_get_type - -<SUBSECTION Private> -EvolutionImporterClient - -</SECTION> diff --git a/doc/devel/importer/evolution-shell-importer.args b/doc/devel/importer/evolution-shell-importer.args deleted file mode 100644 index e69de29bb2..0000000000 --- a/doc/devel/importer/evolution-shell-importer.args +++ /dev/null diff --git a/doc/devel/importer/evolution-shell-importer.hierarchy b/doc/devel/importer/evolution-shell-importer.hierarchy deleted file mode 100644 index c46ebdf782..0000000000 --- a/doc/devel/importer/evolution-shell-importer.hierarchy +++ /dev/null @@ -1,7 +0,0 @@ -GtkObject - BonoboObject - BonoboXObject - EvolutionImporter - EvolutionImporterListener - Handle to remote Bonobo::Unknown - EvolutionImporterClient diff --git a/doc/devel/importer/evolution-shell-importer.types b/doc/devel/importer/evolution-shell-importer.types deleted file mode 100644 index e787818599..0000000000 --- a/doc/devel/importer/evolution-shell-importer.types +++ /dev/null @@ -1,9 +0,0 @@ -#include <gnome.h> -#include <bonobo.h> -#include <shell/importer/evolution-importer.h> -#include <shell/importer/evolution-importer-client.h> -#include <shell/importer/evolution-importer-listener.h> - -evolution_importer_get_type -evolution_importer_client_get_type -evolution_importer_listener_get_type diff --git a/doc/devel/importer/private-reference.sgml b/doc/devel/importer/private-reference.sgml deleted file mode 100644 index d28c7b8591..0000000000 --- a/doc/devel/importer/private-reference.sgml +++ /dev/null @@ -1,21 +0,0 @@ - <reference id="importer-private-reference"> - <title>Importer Private API Reference</title> - - <partintro> - <para> - This part presents the class and function reference for the - private APIs of the different components of the &Evolution; - Import Framework. - </para> - </partintro> - - &EvolutionImporterListener; - &EvolutionImporterClient; - </reference> - -<!-- -Local variables: -mode: sgml -sml-parent-document: ("../evolution-devel-guide.sgml" "book" "part" "") -End: ---> diff --git a/doc/devel/importer/public-reference.sgml b/doc/devel/importer/public-reference.sgml deleted file mode 100644 index ba99c9b309..0000000000 --- a/doc/devel/importer/public-reference.sgml +++ /dev/null @@ -1,20 +0,0 @@ - <reference id="importer-public-reference"> - <title>Importer Public API Reference</title> - - <partintro> - <para> - This part presents the class and function reference for the - public APIs of the different components of the &Evolution; - Import Framework. - </para> - </partintro> - - &EvolutionImporter; - </reference> - -<!-- -Local variables: -mode: sgml -sml-parent-document: ("../evolution-devel-guide.sgml" "book" "part" "") -End: ---> diff --git a/doc/devel/importer/tmpl/evolution-importer-client.sgml b/doc/devel/importer/tmpl/evolution-importer-client.sgml deleted file mode 100644 index 6cee37bef1..0000000000 --- a/doc/devel/importer/tmpl/evolution-importer-client.sgml +++ /dev/null @@ -1,84 +0,0 @@ -<!-- ##### SECTION Title ##### --> -EvolutionImporterClient - -<!-- ##### SECTION Short_Description ##### --> -A #GtkObject based client to simplify use of a GNOME_Evolution_Importer object. - -<!-- ##### SECTION Long_Description ##### --> -<para> -This #GtkObject provides a convience wrapper to the GNOME_Evolution_Importer object, providing error checking and hiding all the CORBA internals from the user. -</para> - -<!-- ##### SECTION See_Also ##### --> -<para> - -</para> - -<!-- ##### MACRO EVOLUTION_IMPORTER_CLIENT ##### --> -<para> -Casts a #GtkObject into an #EvolutionImporterClient -</para> - -@obj: A #GtkObject - - -<!-- ##### FUNCTION evolution_importer_client_new ##### --> -<para> - -</para> - -@objref: -@Returns: - - -<!-- ##### FUNCTION evolution_importer_client_new_from_id ##### --> -<para> - -</para> - -@id: -@Returns: - - -<!-- ##### FUNCTION evolution_importer_client_support_format ##### --> -<para> - -</para> - -@client: -@filename: -@Returns: - - -<!-- ##### FUNCTION evolution_importer_client_load_file ##### --> -<para> - -</para> - -@client: -@filename: -@folderpath: -@Returns: - - -<!-- ##### FUNCTION evolution_importer_client_process_item ##### --> -<para> - -</para> - -@client: -@listener: -<!-- # Unused Parameters # --> -@callback: -@closure: - - -<!-- ##### FUNCTION evolution_importer_client_get_error ##### --> -<para> - -</para> - -@client: -@Returns: - - diff --git a/doc/devel/importer/tmpl/evolution-importer.sgml b/doc/devel/importer/tmpl/evolution-importer.sgml deleted file mode 100644 index 1c7736a37f..0000000000 --- a/doc/devel/importer/tmpl/evolution-importer.sgml +++ /dev/null @@ -1,96 +0,0 @@ -<!-- ##### SECTION Title ##### --> -EvolutionImporter - -<!-- ##### SECTION Short_Description ##### --> -A #BonoboObject that implements the GNOME/Evolution/Importer interface. - -<!-- ##### SECTION Long_Description ##### --> -<para> -A #BonoboObject wrapper around the GNOME/Evolution/Importer interface, providing error checking and reference counting, hiding the CORBA internals from the user and providing a simple way to create a GNOME_Evolution_Importer object. -</para> - -<!-- ##### SECTION See_Also ##### --> -<para> - -</para> - -<!-- ##### MACRO EVOLUTION_IMPORTER ##### --> -<para> -Casts a #GtkObject into an #EvolutionImporter. -</para> - -@obj: A #GtkObject. - - -<!-- ##### USER_FUNCTION EvolutionImporterSupportFormatFn ##### --> -<para> -The type of function that is called when the importer wishes to find out if the importing component can support the file given in @filename. -</para> - -@importer: The #EvolutionImporter. -@filename: The filename of the file to check. -@closure: The data passed into evolution_importer_new (). -@Returns: A #gboolean. TRUE if the importing component can import the file, FALSE otherwise. - - -<!-- ##### USER_FUNCTION EvolutionImporterLoadFileFn ##### --> -<para> -The type of function that is called when the importer wishes the importing component to load the file given in @filename, and initialise itself. -</para> - -@importer: The #EvolutionImporter. -@filename: The filename of the file to load. -@folderpath: -@closure: The data passed into evolution_importer_new (). -@Returns: A #gboolean. TRUE if the load and initialisation was successful, FALSE otherwise. - - -<!-- ##### USER_FUNCTION EvolutionImporterProcessItemFn ##### --> -<para> -The type of function that is called when the importer wants the importing component to process the next item (or items) in a file. -</para> - -@importer: The #EvolutionImporter -@listener: A GNOME_Evolution_Importer_Listener CORBA object. -@closure: The data passed into evolution_importer_new (). -@ev: A #CORBA_Environment for returning any CORBA exceptions. - - -<!-- ##### USER_FUNCTION EvolutionImporterGetErrorFn ##### --> -<para> -The type of function that is called when the importer wants to get a string version of an error. Not all importing components support this function. -</para> - -@importer: The #EvolutionImporter. -@closure: The data passed to evolution_importer_new (). -@Returns: A string representation of the error, or NULL if there was no error, or the importing component does not support the getError method. - - -<!-- ##### ENUM EvolutionImporterResult ##### --> -<para> - -</para> - -@EVOLUTION_IMPORTER_OK: -@EVOLUTION_IMPORTER_UNSUPPORTED_OPERATION: -@EVOLUTION_IMPORTER_INTERRUPTED: -@EVOLUTION_IMPORTER_BUSY: -@EVOLUTION_IMPORTER_NOT_READY: -@EVOLUTION_IMPORTER_UNKNOWN_DATA: -@EVOLUTION_IMPORTER_BAD_DATA: -@EVOLUTION_IMPORTER_BAD_FILE: -@EVOLUTION_IMPORTER_UNKNOWN_ERROR: - -<!-- ##### FUNCTION evolution_importer_new ##### --> -<para> - -</para> - -@support_format_fn: -@load_file_fn: -@process_item_fn: -@get_error_fn: -@closure: -@Returns: - - diff --git a/doc/devel/importer/tmpl/evolution-shell-importer-unused.sgml b/doc/devel/importer/tmpl/evolution-shell-importer-unused.sgml deleted file mode 100644 index 7a9a98034b..0000000000 --- a/doc/devel/importer/tmpl/evolution-shell-importer-unused.sgml +++ /dev/null @@ -1,10 +0,0 @@ -<!-- ##### USER_FUNCTION EvolutionImporterClientCallback ##### --> -<para> - -</para> - -@client: -@result: -@more_items: -@data: - diff --git a/doc/devel/preface.sgml b/doc/devel/preface.sgml deleted file mode 100644 index fdaa824a8b..0000000000 --- a/doc/devel/preface.sgml +++ /dev/null @@ -1,113 +0,0 @@ - <preface id="introduction"> - <title>Introduction</title> - - <para> - This is the &Evolution; Developer's Guide or programming guide - for the &Evolution; groupware suite. If you are a programmer - and you wish to use &Evolution;'s functionality from your own - applications or if you wish to modify the &Evolution; core code, - you should read this guide. - </para> - - <para> - If you are an end-user of &Evolution; you do not need to read - this guide; please read the &Evolution; User's Guide instead. - </para> - - <para> - This guide contains the information you need to know to do the - following: - - <itemizedlist> - <listitem> - <para> - Write applications that use &Evolution;'s data - repositories via the &Wombat; personal information server. - Examples of this would be a <application>GNOME - Panel</application> applet that displays today's - appointments, or a telephone dialer application that uses - the contents of the &Evolution; Addressbook. - </para> - </listitem> - - <listitem> - <para> - Write applications that use the &Camel; mail library. - This includes extending &Evolution;'s own mail component - to perform additional functions. - </para> - </listitem> - - <listitem> - <para> - Write new components for the &Evolution; Shell. Instead - of writing a stand-alone application, you can provide your - users with the benefit of having integrated views of their - data from within Evolution. - </para> - </listitem> - - <listitem> - <para> - Write new modules for the &Evolution; Executive Summary. - This allows you to present commonly-accessed information - in a convenient fashion directly in the &Evolution; Shell. - </para> - </listitem> - - <listitem> - <para> - Modify the core &Evolution; code to add new features or - change its architecture. - </para> - </listitem> - </itemizedlist> - </para> - - <sect1 id="organization"> - <title>Organization of this Guide</title> - - <para> - This guide is organized in two big sections. The first is a - programming guide, which consists of one part for each one of - &Evolution;'s components: there are separate parts for the - calendar, the addressbook, the mailer, the executive summary, - and the shell. Each part gives a description of the - architecture of its corresponding component, and also gives - information about the component's internal architecture and - some implementation details. - </para> - - <para> - The second section of this guide is a reference guide for - &Evolution;'s programming interfaces. We have separated these - into public and private interfaces. The public ones are those - that most people will need to use when writing extensions or - third-party components; the private interfaces are those used - internally in &Evolution;. Even if you do not intend to - modify the &Evolution; core code, it may be useful to know a - bit about the way it is organized internally. - </para> - - <para> - &Evolution; is free software, and we want you as a programmer - to make the most of it. We have provided many useful - interfaces that you can use in your own applications. Still, - we want you to view &Evolution; as a framework for building - groupware applications, and this may occasionally involve - making changes to its core code. We want you to learn from - &Evolution;'s design because we think it marks an important - milestone in the development of large-scale free software - applications. We want you to modify it as you see fit. Free - software gives you this freedom, and we want the whole world - to benefit from it. - </para> - </sect1> - </preface> - -<!-- -Local variables: -mode: sgml -sgml-parent-document: ("evolution-devel-guide.sgml" "book" "book" "") -End: ---> diff --git a/doc/devel/reference.sgml b/doc/devel/reference.sgml deleted file mode 100644 index 4381ad29b7..0000000000 --- a/doc/devel/reference.sgml +++ /dev/null @@ -1,49 +0,0 @@ - <part id="evolution-api-reference"> - <title>&Evolution; API Reference</title> - - <partintro> - <para> - This part presents the class and function reference for the - different libraries and interfaces that &Evolution; provides. - Classes are described together with their methods; individual - functions are grouped by functional group. - </para> - - <para> - &Evolution; provides two kinds of interfaces, public and - private. The public interfaces are those designed to be used - from third-party applications or components; if you wanted to - write an application that uses &Evolution;'s data repositories - to display data in a particular way, you would use the public - interfaces. The private interfaces are those used inside - &Evolution; itself; these are generally not interesting unless - you intend to make modifications to the &Evolution; code base. - </para> - - <para> - While the public and private interfaces are described in - separate reference sections, we have decided to put them - together in the same book, this guide, because we want to - encourage you to regard &Evolution; as something more than a - black box that stores and dispatches personal information. We - want you to make modifications to the &Evolution; core if - these would allow you to present or store your data in better - ways. &Evolution; is free software; we want you to learn from - its design and implementation details so that you can make it - even better for the whole world to use. - </para> - </partintro> - - &calendar-public-reference; - <!-- &importer-public-reference; --> - <!-- &evolution-services-public-reference; --> - <!-- &importer-private-reference; --> - <!-- &evolution-services-private-reference; --> - </part> - -<!-- -Local variables: -mode: sgml -sgml-parent-document: ("evolution-devel-guide.sgml" "book" "book" "") -End: ---> 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> |
