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  -  [EMAIL PROTECTED]
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
[EMAIL PROTECTED]  - www.ximian.com

_______________________________________________
evolution-hackers maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution-hackers

Reply via email to