Re: [HACKING] Mailbox tree rewrite

[Ian Campbell <ijc25 cam ac uk>]

Pawel, 

here are some comments I had on this. I also have outlined what I was
thinking of earlier in the year in terms of how I would do it.

One quick comment first though: You have abriviated some of the names, I
think that was just for clarity here - I personally much prefer to spell
stuff out in full in code.

Anyway, when I was considering the whole thing some time ago, I thought
about expanding a LBMailbox to have a list of children. I didn't intend to
make any distinction between "Sets" and "Leaves" as you have, but simply
said that a mailbox with no children was a leaf. My thinking was that it
was simpler, and also it allows things like the IMAP implementation to
represent both IMAP directories and the folders within them.

I was also intending to have some sort of "my list of children changed"
signal which could be emmited, for example when a new folder is detected.

In scheme B you mention that each Leaf would reference a LBMailbox, this
sounds much like the purpose the current LBServer objects are supposed to
fullfill, I was thinking that a subtree of Mailboxes from an IMAP server
would all reference the same LibBalsaServerIMAP (or whatever) which would
provide much of the actual functionality I guess.

I don't like the idea of having the mailboxes know how to insert themselves
into a GtkCTree (or whatever) because I think it breaks the distinction
between the GUI and the backend stuff (which I would like to keep
separate). It should not be necessary anyway, because the GUI code can
simply walk a mailboxes children and do the insertions and then hook to the
children-changed signal to keep track of updates.

I'm also not convinced about having the mailboxes return widgets to edit
themselves, again it breaks the distinction between GUI and backend. I
don't think the current way of doing stuff would be too bad if we cleaned
it up a bit (well, a lot). 

I had some vague idea about generating the config dialog from the objects
arguments, but I don't think that is feasible. A wonder how PonG would work
though...

We already have save/load conf, and I like it a lot...

Hopefully we can make much better use of object ref counting to save us
some headaches.

One other thing was that I was thinking it might be worthwhile to separate
the interactive mailboxes (ie Local ones and IMAP) from the 'download only'
(POP3 and potentially IMAP too), since the two concepts are quite
different. Perhaps a new hierarchy based around 'LibBalsaMailSource' or
some such...

The other thing I would like to do is to make each of the 3 local mailbox
types be a separate object, and require the user to create mailboxes of the
appropriate type, this would save all sorts of confusion with detecting the
type of a mailbox, and would potentially allow su to take advantage of the
benfits of the different types of mailbox in a cleaner way. (eg checking
for new messages in a maildir..)

Well, those are my comments, I hope they make sense
Ian.

On 2000-11-15 20:43:54 +0000 Pawel Salek wrote:
> Hi,
> 
> I have started the mailbox tree redesign in order to implement "properly"
> mailbox tree edition (both local and remote IMAP). 
> 
> I have come up with following class structure (A):
> 
> GtkObject -> LBMailboxNode -> LBMailbox (and here existing MB types)
>                            -> LBMailboxSet -> LBMSLocal (dir)
>                                            -> LBMSRemote(imap)
> 
> LibBalsaMBNode (called MN later) are associated with the visible nodes in
> the mailbox tree. They come basically in two flavours: leaves (which are
> actual mailboxes that can be read, etc., and their parents (which can be
> a
> mailbox directories, whole imap servers etc.) Leaves=mailboxes could be
> rooted also at the top level.
> 
> Alternative strategy would be to create following structure (B):
> 
> GtkObject -> LBMailboxNode -> LBMBLeaf 
>                            -> LibBalsaMailboxSet -> LBMSLocal (dir)
>                                                   -> LBMSRemote(imap)
> 
> where LBMBLeafs own (or link to) LBMailbox as they are defined today.
> This
> would separate better GUI (where LBMailboxNode belong) and backend
> (Mailbox
> objects).
> 
> Each MailboxNode will have following methods:
> 
> insert_to_gtktree() - inserts itself to the mailbox tree (mailboxSets ask
> their children to intsert themselves recursively).
> 
> static::get_edit_widget() - returns a widget for given MN class.
> 
> fill_edit_widget() - fills given edit widget with MN data. These two
> functions are separated to allow: a) creation of new MNs, b) attribute
> reset,
> 
> set_from_widget() - sets MN fields from the edit widget.
> 
> static::load_conf() - creates new NM from the configuration data
> 
> save_conf() -- saves itself to the configuration (note that automatically
> generated nodes like those created by scanning directories or imap
> servers
> will leave this job to their parents).
> 
> Any comments? Suggestions?
> 
> /Pawel
> -- 
> Pawel Salek, pawsa@theochem.kth.se
> 
> 
> _______________________________________________
> balsa-list mailing list
> balsa-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/balsa-list
> 



-- 
Ian Campbell
Churchill College, Cambridge.