[Evolution-hackers] Status of mail-refactor-2 branch todo

[Not Zed <notzed ximian com>]

Although i've been updating the web log with 'points of interest',
here's a more thorough update on the state of the branch, a followup to
my earlier mail about it.  Excellent progress has been made, and the
code is nearing merge readiness.

Might even investigate some more plugin ideas while i've got it on my
mind.

Anyway, "the story so far":

Clean up printfs
- some done
Clean up warnings (missing headers mostly)
- some done
Some above-api documentation.
- some done
Testing of shutdown cases (e.g. shutdown while busy, during setup, etc)
- a little done.  stable.  more needs to be done with remote imap   
  attachments etc.

X Context menu's, bonobo does some popup stuff but ui's not simple ...
 - context menu creation process still needs tweaking, multiple 
	contributors
   to the menu
 - done, popup's can be added to from anywhere, customised, etc = more 
	functionality, less code.

EMMessageBrowser
	Shouldn't update any gconf settings
	Review menu's for applicability and perhaps add some missing ones.
 - not done

EMFolderView
	Needs to setup galview menu's, etc.  c&p from FolderBrowser.
 - done
	Status line not implemented.  Depends on new shell design.
 - waiting on shell
	Context menu ...
 - done
	Key binding stuff.  Some should go to messagelist.
 - done afaik, most couldn't go to messagelist
	Double-click should open message
 - done
	Customising menu's/activation based on current selection/message
 - done
	Empty trash not implemented.
 - done
	Expunge implemented but may need tweaking.
 - wait and see how it works now

  emfv_add_sender_addressbook
	New ebook api not finished yet, not worth porting till it is
 - waiting on addressbook

  emfv_message_copy
  emfv_message_move
	Requires differnet code for new shell, a folder selector widget.
 - waiting on shell stuff

  emfv_message_reply
	Would be nice to get the reply-to-selected-text working, it's
	mostly there.
 - no progress, it's still mostly there.  IMHO easiest is just for
gtkhtml to clear its primary selection pointer when it loses the
selection, it isn't useful for anything at that point.  but there are
other solutions too.

EMFolderBrowser
-NO-	What happened to hide subject/hide sender?  code there, not 
	used.
 - old dead code
	Context menu ...
 - done
	MessageList focus? (see folder-browser.c)
 - not done (menu activation based on message-list focus)
 - messagelist should probably have an activate(uic) call

EMFormat
	More testing.  Memory leak checking.
 - fixed some minor bugs

EMFormatHTML
	More testing, particulary of multipart/related, content-location
	stuff, and some of the threading stuff - though it seems pretty 
	solid.
 - multipart/related inside multipart/related may cause problems
 - fixed some bugs
	Proxies for remote stuff
 - http proxies done, but not tested (may need camel-http-stream work if
	it doesn't work)
	Some small memory leaks if you cancel
 - not fixed

EMFormatHTMLDisplay
	Popup menu's, some can be linked from EMFolderView?
 - done
	Link clicking, EMFolderView again?
 - done
	Icon generation/display
 - done, alhtough needs a cache for image icons
	Jumping when we expand attachments - can ever make one-pass 
	render work?
 - still no idea on this one
	Should this become UIComp activate/deactivate aware for custom
	menus.
	  - can this extend to popups, or does it need to build a popup 
	on the fly?
 - popups done in simpler manner
 - i dont think we need menu's ontop of those, so probably ok

MessageList
	Should this become UIComp activate/deactivate aware for custom 
	menus.
	  - can this extend to popups, or does it need to build a popup 
	on the fly?
  - as above, this probably needs uicomp activate/deactivate

What about composer, can any cleanup be done there?
 - 'good enough for now'

The rest of the stuff is unstarted and will not be performed on the
mail-refactor-2 branch.

CamelFolder - need to have delayed open/etc.

First cut - simply move open code from construct to an open method.
  2-3 days work

Second cut - remove CamelFolderInfo stuff, and have CamelFolder the
 only tree data to scan?  Would still need CamelStoreInfo to store
 the structure of the messages, or perhaps just a serialise method on
 the folder objects?
  At least a week?

CamelFolder - remove open flags, use persistent folder properties
instead.
  1-2 days work

Camel*Store - need a store that stores sub-directories in mozilla/ns
format, for use as the main data store for evolution, or just settle
on Maildir?  Should it support alternate backends, or just fix on one
(Maildir or mbox).

S/MIME - need to at least investigate the featureset required.