[Evolution-hackers] progress update

[Not Zed <notzed ximian com>]

He's a bit of an update of the stuff i've been working on in the last
week or so.  Refactoring of the mail display code has been the priority
for now.

The main goal i'm trying to achieve is to separate all the inter-twined
spaghettiness of the code and restore the structural integrity and
separation of the functionally distinct components.  i.e. make it more
maintainable and reusable and clean out the rot.

Extensibility is a further goal which can be considered thereafter.

Anyway, a summary of "the story so far" and progress follows:

old:

MailDisplay
	mail-display.[ch] (gone)
	mail-format.[ch] (gone)
	mail-identify.[ch] (gone)
	mail-display-stream.[ch] (slight changes)
	e-searching-tokenizer.[ch] (unchanged)
	mail-search.[ch] (needs cleanup, gladeifying)
	???

new:

possible class layout, not that happy with the subclass's names

EMailDisplay
	- Uses an EFormatHTMLDisplay for all generation/layout
	- intended for all gui related stuff not included inline in the html
display
	  - Handles popup menu's
	  - Handles link clicks
	- not yet implemented

EMailFormat
	- Implements architecture for driving the formatter
	- all output driven through camelstream's
	- provides hooks for tracking related parts
	- provides hooks for tracking user-toggled inline attachments
 	- implements the basic structural types (multipart, message)
	- various utility functions like wrapping a file in a mimepart, for
icons
	- has no knowledge of EMailDisplay, or other objects

	EFormatHTML
		- a concrete implementation of emailformat for html parts
		- uses gtkhtml for html parsing
		- implements all functionality used for inline display
		- needs to use threads to load offline parts

		EFormatHTMLDisplay
			- adds theme tracking
			- adds interactive elements; attachment toggles, signature buttons
			- with some minor gtkhtml support, should be able to handle
attachment
			  and signature stuff without having to redraw
			- generally no need for EMailDisplay to access GtkHTML api's directly
			  - exports events for link clicks and popup invocation
			  - searching
			- intention for it not to drive any child windows

		EFormatHTMLPrint
			- basically adds a print method to EFormatHTML
			- abstracts widget niggles like realising in a toplevel
			  (if its still needed?)

	EFormatHTMLReply
		- for generating replies?
		- not yet implemented

	EFormatAttachments
		- to save attachments?
		- not yet implemented

ECamelStream
	- MailDisplayStream with some tweaks
	- more complete abstraction
	  - handles closing and implicit refcounting of GtkHTML stream
	  - also flushing of idle events, etc.
	- also to be extended to handle cross-thread use

TODO:

from mail-format.c:

95% - message headers
50% - verify text to html flags right
50% - xmailer stuff (do we still want it?)
00% - background loading of offline parts
40% - formatting, e.g. <hr> separators, padding, borders
00% - text_plain: mark citations - is it still used?
00% - text/plain preferred for alternative - is it still used?
50% - reply formatting?

from mail-display.c

00% - signature handling button (default is to verify), need gtkhtml
support, or redraw
      should we consider different signature verification ui?
00% - attachments dont collapse, need gtkhtml support, or redraw
20% - popup menu's, api for details already there
40% - following links, api for details there
00% - fetching remote data (can we kill soup?  camelhttpstream would fit
	easiest, but needs to lose camelservice requirement)
00% - drag and drop, can we add it to messages?  inline messages?
00% - saving things
00% - image/* icon generation (other icons are loaded from disk on
demand)
00% - bonobo component stuff
00% - charset override handling (good time to look at camelmimepart
changes?)
90% - printing
75% - searching