Re: [RFC] : coherent message add/delete notification
- From: Emmanuel <e allaud wanadoo fr>
- To: balsa-list gnome org
- Subject: Re: [RFC] : coherent message add/delete notification
- Date: Sat, 1 Jun 2002 14:57:24 +0200
On 01.06.2002 01:57 Carlos Morgado wrote:
> On Fri, May 31, 2002 at 06:52:37PM +0200, Emmanuel wrote:
> > Hi all,
> > Tim and I was discussing about filters being run upon reception that
> > let deleted messages even if you had checked "hide deleted" or "delete
> > irremediably...".
> > Finally I think this is an issue rooted deeper than filters. For me it
> > the add/delete messages scheme that lacks a coherent notification. We
> This was touched lightly while discussing upgrade path for
> balsa2 the new treemodels.
Oh I'll try to have a look.
> > The way I would do it :
> > * all backend messages moving/copying messages and involving a
> > mailbox should send the notification themselves : in fact there is now
> > only libbalsa_message[s]_copy(dest_mailbox,messages) in that case, and
> > should tell the dest_mailbox that it has new messages (sending it the
> > "MESSAGES_NEW" message).
> there's also new messages appearing on storage. that's the worse
> case for notifications
I don't get it here, what are you talking about please ?
> > * all backend messages moving/copying messages not involving a
> > mailbox should not notify themselves; indeed for example think of
> > libbalsa_messages_delete(messages), their is no garantee that the list
> > messages to delete all come from the same mailbox, so there, this
> imo this is somewhat evil, but neatly correct abstraction wise.
> currently i don't see a situation were you can delete messages from
> diferent mailboxes but with filtered view that is a possibility
Yes it seems a bit overkill for now, but I have in mind that things will
get a bit more complicated later so let's do it quite flexible to be able
to handle all cases later.
> > be the responsability of the caller (which knows about the mailbox[es]
> > being altered) to send the notification (ie send "MESSAGES_DELETE" to
> > mailbox[es]).
> messages point back to their mailboxes so it's not actually a problem
> to raise signals from _delete.
Yes but this would lead to a storm of notification (one for each message)
if you delete a bunch of messages, instead of just one for the whole list
(or perhaps one per touched mailbox if there are several involved)
> > Is this OK for everyone, comments?
> it was proposed having LibBalsaMailbox keeping track of the GtkTreeModel
> that represents it but there may exist filtered views that span multiple
> mailboxes and multiple views of the same mailbox with diferent
> so, frontend keeps the Trees and gets notified of changes, but that gets
> sticky if you delete a bunch of messages that exist on several views.
> for me the nicest approach would be to keep a treemodel in libbalsa and
> then create treemodels for the views referencing that models. i'm not
> how well this would work or muck with gtk internal - some reading must
> be done.
> this would get us:
> * hopefuly, automagic coherency :)
> * soft and hard views. using some clever (de)referencing we get views
> capable of keeping messages alive/deleting messages and soft "readonly"
I guess we can do it more or less that way (not actually detailed but
that's just the basic idea). The backend (in that case the LibBalsaMailbox
and the LibBalsaMessage's) is responsible of obeing orders from frontend :
delete,move,copy whatever. Datas are changed, and the notification of
these changes are sent in the wild (following the scheme I described),
that way all views can connect to this notification to keep up to date.
For example : imagine you have an index open on the mailboxes A and B, a
filtered view with messages from mailboxes A,B. OK so the user delete
several messages by the index (popup menu, whatever), the notification is
sent to : the index itself (and the callback just delete the messages, and
even tell the mailbox to actually drop the messages if user pref says to
do so), the filtered view also catches the notif and refresh itself if it
was displaying part of the deleted messages.
Now you click on "Check Mail". New messages in A,B --> notif to all views
that add them, imagine that view B has a filter on reception that moves
matching messages to mailbox C. So there is a notif of deletion for all
matching messages of B that are moved to C, and then the index and the
view update themselves accordingly. And so on.
What I mean is that this scheme it complementary of the GtkTreeModel
thing. Perhaps we should just centralize notif to the tree model that
repercute them to views depending on the user prefs, but that is just
] [Thread Prev