Re: [RFC] : coherent message add/delete notification

[Carlos Morgado <chbm chbm nu>]

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 will 
> 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 is 
> the add/delete messages scheme that lacks a coherent notification. We 

This was touched lightly while discussing upgrade path for
balsa2 the new treemodels.

> 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 it 
> 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

> 	* 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 of 
> messages to delete all come from the same mailbox, so there, this should 

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

> be the responsability of the caller (which knows about the mailbox[es] 
> being altered) to send the notification (ie send "MESSAGES_DELETE" to the 
> mailbox[es]).
> 
messages point back to their mailboxes so it's not actually a problem
to raise signals from _delete.

> 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
sort/threading. 
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 sure
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"
 views


as for 1.4, i think we can acomodate for whatever you need as long as it
doesn't bend current structure too much. after all, that branch is a
devel dead end. pawel ?

-- 
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A 
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
"Some people have told me they don't think a fat penguin really embodies the
grace of Linux, which just tells me they have never seen a angry penguin 
charging at them in excess of 100mph. They'd be a lot more careful about 
what they say if they had." -- Linus Torvalds