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.



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

Reply via email to