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

[Not Zed <notzed ximian com>]

On Fri, 2003-09-05 at 13:22, Ettore Perazzoli wrote:
> > 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.
> 
> This looks awesome!  Thanks for the detailed update.
> 
> > EMFolderView
> > 	Needs to setup galview menu's, etc.  c&p from FolderBrowser.
> >  - done
> > 	Status line not implemented.  Depends on new shell design.
> 
> Actually I am not sure how to do this right now, all the status bar
> stuff is disabled on the new-ui-branch.

I'm not sure if i made it clear, the 'status bar' i was referring to
here is the abominationational waste of space at the top of the screen.

I think you're referring to the bar at the bottom of the window, which
code hasn't changed in our branch.

> We could do one of these things:
> 
>       * Keep the same interface as before on the control frame.  It does
>         have a few problems (which you outlined earlier), but at least
>         it would require almost no work to get it working again.
> 
>       * Just let each component handle the status bar on its own, and
>         export it as a control.  This should make the implementation
>         trivial, however it won't let you see what e.g. the mailer is
>         doing when you have the calendar selected.
> 
>       * Come up with a different interface, and possibly a different UI
>         way of doing it.

I proposed an alternative interface some time ago, which would simplify
things a bit and reduce some of the overhead.

> What are your thoughts?

I think we need to have some globally accessible object to handle it,
not handled by each component.  So either leave as is or redesign a bit
- its not very complex so it shouldn't need much work.

Different ui could be an option too (although i dont see what else would
be very practical).

> >  - waiting on shell
> > 	Context menu ...
> 
> In the new UI, the shell will not handle the folder context menus
> anymore, so you'll just have to hook the menus to the EStorageSetView
> widget within the mailer.
> 
> (Or do you mean the message context menus as well?)

Well i meant the internal ones, which are all done.  Remember on our
branch we still have the existing shell stuff.  Adding new (extensible)
popups in the mailer is now so trivial ...

Do we have to use EStorageSetView at all?

> >  - 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
> 
> BTW while you are massaging this code, can we make it so it jumps to the
> first unread message when you first click on the folder?

Shouldn't be too hard.  Gotta be optional though.

> (Actually I am not sure if it should do it after the first time as
> well...  What do other clients do?)

Good question.

> >   emfv_message_copy
> >   emfv_message_move
> > 	Requires differnet code for new shell, a folder selector widget.
> >  - waiting on shell stuff
> 
> Nod...  For this we should just be able to stick the
> e-shell-folder-selection-dialog/e-shell-folder-creation-dialog code in
> libeshell and use that, probably with some minor massaging.
> 
> You just need to provide an EStorageSet for these to work, and I already
> have the mailer handling that on the branch.

FWIW i'm not really fond of these interfaces, but i guess it'll do.

> BTW with the new UI we also need the "Go to folder..." dialog to be
> implemented in the mail component, instead of the shell.

We have a go to folder option?  Hmm, so we do.

Hmm, would this even make sense with the new layout?  The existing
functionality is pretty pointless if you have the folder list open
already, and if the ui will force it to be always open, it makes it even
less useful?

 Z