On Mon, 2003-09-01 at 10:28, Not Zed wrote:
> Jeff, anything on this list take your fancy?  (leave the
> warnings/printf's till we're about to merge I think, some are there as
> placeholders).
> 
> I think I will look into the context menu stuff right now.
> 
> The mailer stuff to be done on the mail-refactor-2-branch as usual.  The
> camel delayed-open stuff would probably want to be another branch on
> camel+mail after we've merged back to head, though design could be any
> time.
> 
> 
> Mail, immediate TODO
> 
> Clean up printfs

I can handlethis, I think :)

> Clean up warnings (missing headers mostly)
> Some above-api documentation.

I wouldn'tmind writing some docs

> Testing of shutdown cases (e.g. shutdown while busy, during setup, etc).
> Context menu's, bonobo does some popup stuff but ui's not simple ...
> 
> EMMessageBrowser
>       Shouldn't update any gconf settings
>       Review menu's for applicability and perhaps add some missing ones.
> 
> EMFolderView
>       Needs to setup galview menu's, etc.  c&p from FolderBrowser.
>       Status line not implemented.  Depends on new shell design.
>       Context menu ...
>       Key binding stuff.  Some should go to messagelist.
>       Double-click should open message
>       Customising menu's/activation based on current selection/message
>       Empty trash not implemented.
>       Expunge implemented but may need tweaking.
> 
>   emfv_add_sender_addressbook
>       New ebook api not finished yet, not worth porting till it is
> 
>   emfv_message_copy
>   emfv_message_move
>       Requires differnet code for new shell, a folder selector widget.
> 
>   emfv_message_reply
>       Would be nice to get the reply-to-selected-text working, it's
>       mostly there.

I might be interested in hacking on this a bit

> 
> EMFolderBrowser
>       What happened to hide subject/hide sender?  code there, not used.
>       Context menu ...
>       MessageList focus? (see folder-browser.c)
> 
> EMFormat
>       More testing.  Memory leak checking.

I can try valgrinding some of this

> 
> EMFormatHTML
>       More testing, particulary of multipart/related, content-location stuff,
>       and some of the threading stuff - though it seems pretty solid.

I've got a mailbox full of sample messages for this that I can test
against and use to tweak, so I wouldn't mind taking this on.

> 
> EMFormatHTMLDisplay
>       Popup menu's, some can be linked from EMFolderView?
>       Link clicking, EMFolderView again?
>       Icon generation/display
>       Jumping when we expand attachments - can ever make one-pass render
> work?
>       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?
> 
> 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?
> 
> What about composer, can any cleanup be done there?

the composer can probably mostly stay as is for now, afaik there aren't
any major shortcomings.

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

yea, that's what I'm thinking

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

I wouldn't mind writing a Mozilla-like camel provider.

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

we probably need to poke the Novell guys and get their feature set and
try to mimic theirs?

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