diff options
Diffstat (limited to 'doc/devel')
21 files changed, 0 insertions, 4991 deletions
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 9de1bb25a1..0000000000 --- a/doc/devel/ChangeLog +++ /dev/null @@ -1,42 +0,0 @@ -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/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 a8f01ac954..0000000000 --- a/doc/devel/evolution-plugin-manual.xml +++ /dev/null @@ -1,3010 +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"> - -]> -<?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> ? - <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>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" - ... - <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> - </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 - type="pass | sink" - priority="signed integer" - id="event name" - enable="target mask" ? - handle="function spec"/> * - </event> * -</hook>]]></programlisting> - <variablelist> - <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>id</parameter></term> - <listitem> - <simpara> - The name of the event to listen to. - </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>Name</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>com.ximian.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> - - <sect2> - <title>Folder Tree Context Menu</title> - <para> - This is the context menu shown on 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><interfacename>com.ximian.mail.storageset.popup.select</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-popup-EMPopupTargetFolder">EMPopupTargetFolder</link> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect2> - - <sect2> - <title>Message List Context Menu</title> - <para> - This is the context menu shown on the 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><interfacename>com.ximian.mail.folderview.popup.select</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-popup-EMPopupTargetSelect">EMPopupTargetSelect</link> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect2> - - <sect2> - <title>Inline URI Context Menu</title> - <para> - This is the context menu shown when clicking on inline URIs, - including addresses or normal HTML links that are displayed inside - 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><interfacename>com.ximian.mail.folderview.popup.uri</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry><link - linkend="mail-hooks-popup-EMPopupTargetURI">EMPopupTargetURI</link></entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect2> - - <sect2> - <title>Inline Content and Attachment Context Menu</title> - <para> - This context menu is shown when right-clicking on inline images, or - when clicking on the attachment expander button. - </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><interfacename>com.ximian.mail.formathtmldisplay.popup.part</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry><link - linkend="mail-hooks-popup-EMPopupTargetPart">EMPopupTargetPart</link></entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect2> - - <sect2> - <title>Composer Attachment Bar Context Menu</title> - <para> - This context menu is displayed when the user brings up a context - menu on the attachment bar displayed in the 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><interfacename>com.novell.evolution.mail.composer.attachmentBar</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry><link - linkend="mail-hooks-popup-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> - </sect2> - - <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>com.ximian.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> - - <sect2> - <title>Main Mail Menu</title> - - <para> - This is the main mail view embedded in the &Evolution; Shell. - </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><interfacename>com.novell.evolution.mail.browser</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-menu-EMMenuTargetSelect">EMMenuTargetSelect</link> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect2> - - <sect2> - <title>Standalone Message View Menu</title> - - <para> - This is the popup mail-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><interfacename>com.novell.evolution.mail.messagebrowser</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-menu-EMMenuTargetSelect">EMMenuTargetSelect</link>, - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect2> - - <sect2> - <title>Composer Menu</title> - <para> - This is the mail message composer. This is currently not implemented. - </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><interfacename>com.novell.evolution.mail.composer</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry>Undefined</entry> - </row> - <row> - <entry>Qualifiers</entry> - <entry>Undefined</entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect2> - - <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>com.novell.evolution.mail.config:1.0</interfacename>. - </para> - - <sect2> - <title>Account Editor Druid</title> - <para> - This is the GnomeDruid which is shown when you create a new mail account. - </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><interfacename>com.novell.evolution.mail.config.accountDruid</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-config-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> - </sect2> - - <sect2> - <title>Account Editor Window</title> - <para> - This is the editor notebook which is shown when you edit an - existing mail account. - </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><interfacename>com.novell.evolution.mail.config.accountEditor</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="API-struct--EMConfigTargetAccount">EMConfigTargetAccount</link>, plugin target is "<constant>account</constant>". - </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> - </sect2> - - <sect2> - <title>Composer Preferences</title> - <para> - This is the notebook of configuration items for the composer which - are accessed via the main settings window under the Composer tab. - </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><interfacename>com.novell.evolution.mail.composerPrefs</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-config-EMConfigTargetPrefs">EMConfigTargetPrefs</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> - </sect2> - - <sect2> - <title>Mail Preferences</title> - <para> - This is the notebook of configuration items for the mailer which - are accessed via the main settings window under the Mail Settings tab. - </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><interfacename>com.novell.evolution.mail.prefs</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-config-EMConfigTargetPrefs">EMConfigTargetPrefs</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> - </sect2> - - <sect2> - <title>Folder Properties</title> - <para> - This is the notebook of configuration items for a given mail folder - which is accessed via the Folder Properties item in the main menu item or - folder-tree context menu. - </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><interfacename>com.novell.evolution.mail.folderConfig</interfacename></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-config-EMConfigTargetFolder">EMConfigTargetFolder</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> - </sect2> - - <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>com.ximian.evolution.mail.events:1.0</interfacename>. - </para> - - <sect2> - <title>Folder Changed Event</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.changed</constant></entry> - </row> - <row> - <entry>Target</entry> - <entry> - <link - linkend="mail-hooks-event-EMEventTargetFolder">EMEventTargetFolder</link> - </entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect2> - - <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> - None defined. - </para> - </chapter> - - <chapter id="calendar-hooks"> - <title> - Calendar and Tasks Hooks - </title> - <para> - None defined. - </para> - </chapter> - - <chapter id="shell-hooks"> - <title> - Shell Hooks - </title> - <para> - None defined. - </para> - </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/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: ---> |