[HACKING] Mailbox tree rewrite
- From: Pawel Salek <pawsa theochem kth se>
- To: balsa-list gnome org
- Subject: [HACKING] Mailbox tree rewrite
- Date: Wed, 15 Nov 2000 21:43:54 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]