[Evolution-hackers] Prototype patch for new UI

[Ettore Perazzoli <ettore ximian com>]

[Re-sending since I think the mailing list didn't like it with a large
attachment before...]

In order to make sure that the new UI redesign actually makes sense for
the components, I have tried refactoring the shell and the mailer a bit
so I could come up with a prototype...  And the result is the following
(largish) patch:

	http://primates.ximian.com/~ettore/mail-refactor.diff

This is not meant to be the final code, it has a lot of loose ends and
needs to be cleaned up a bunch, but it's a first refactoring step that
could bring us there.

The patch does the following things:

      * It adds a new, very simple Evolution-Component.idl interface
        which is the basis for the "new way" of Evolution components. 
        The new way basically means that components no longer interact
        with the shell for folder management; they just return two
        controls, one for the left pane (calendar/folder/whatever list)
        and one for the right (view pane, e.g. the message list and the
        preview pane).  It's up to the component to do the right thing
        with the two panes.

      * It exports a bunch of currently private shell objects for folder
        management (EStorage, EFolder and friends) through libeshell. 
        It also exports the EStorageSetView widget, which is what we
        currently use for the folder tree.

      * It makes the shell query for components that implement the new
        Component interface and create a view with one button per
        component.  When one of these buttons gets pressed, the shell
        activates the corresponding component, gets the two controls,
        and puts them in the view.  (Please note that a lot of the
        original shell machinery is still in place, although it would
        all disappear eventually.)

      * It implements a simple EBrowser object in libeshell, to handle
        switching views with the tree view.  (The name is unfortunate
        since we already use that name in gtkhtml, but I didn't realize
        at the time.  :-)  We can change it.)

      * It modifies all the storage handling in the mailer code to use
        EStorage and friends instead of the old shell CORBA interfaces.

      * It disables some stuff in the mailer, in particular it removes
        all the LocalStorage handling which is not meant to exist
        anymore.

      * It makes the mailer implement the Component interface, using the
        EBrowser object and the EStorageSetView widget.

      * It refactors the mailer code a bit, removing some globals and
        cleaning up a few things that I noticed while I was refactoring.

With all these changes, I can launch the shell, which in turn activates
the mailer, and browse my (already configured) IMAP mail account from
there.  Of course, local mail doesn't appear at all since that was
previously handled by the shell.

Now assuming the patch is a good starting point the following steps
could be:

      * Finish the refactoring in mail/ and clean up the dirty bits.  (I
        have marked all the open issues I know about with EPFIXME
        comments.)

      * Add support for the local folder tree in the mailer.

      * Clean up the shell so it only uses the new Component IDL.

      * Simplify/generalize the stuff we are now exporting in libeshell
        (e.g. right now the way folder types are defined is all bound to
        the old ShellComponent way of things, which we don't need
        anymore).  Some stuff could also be renamed while we are at it
        (e_storage_set for example).

      * Add support for folder icons again.  (Currently there are no
        icons because of the problems with the type handling in
        libeshell.)

      * Implement folder operations (copy/move/rename/create) in the
        mailer.

      * Put drag and drop support back in.  (This implies taking the
        code in the shell, nuking all the nasty CORBA bridge bits, and
        just use straight signals.)

      * Some other stuff that I have to think about.  :-)

Overall, it seems pretty doable, and would cut down on a lot of nasty
code without actually writing much new.  Some stuff just needs to be
moved around.

Thoughts?

-- Ettore