Re: [Evolution-hackers] progress update



On Thu, 2003-07-03 at 06:05, Not Zed wrote:
> 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?

it seems that mozilla uses a dialog popup to display this sort of
information. might be something to think about.

> 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)

yes, please lets drop soup :-)

> 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

very cool :-)

Jeff

> 
> 
> 
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  - www.ximian.com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]