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

On 01.06.2002 22:00 Peter Bloomfield wrote:
> Hi Manu!
> Pawel has just committed some new BalsaMBList code in the BALSA_2 cvs 
> branch: it now subclasses GtkTreeView, instead of the deprecated 
> GtkCTree. The largest remaining dependence on deprecated objects is 
> BalsaIndex, which also uses GtkCTree (although it is currently a 
> subclass of GtkScrolledWindow!), so porting BalsaIndex is the next big 
> task. Another large step will be moving LibBalsaMailbox and friends from 
> GtkObject to GObject, which will mean revisiting all the mailbox signals.
> So all in all, it's a good time to discuss any signalling changes that 
> are necessary to support filters properly. I'm totally in the dark about 
> how filters are implemented, and what the current problems are. Can you 
> lay the issues out in really simple terms for me?

Hi Peter,
in fact filters have not actually serious issues, just sync problems with 
index : when filters run they take actions on matching messages 
(user-specified : move/copy...). The moves are problematic right now 
because they cause messages to be deleted, and the current scheme of 
balsa-index is, more or less, that deletion will occur from the GUI, so 
that refresh are mostly called in the GUI callbacks themselves.
I think, even outside this filters issue, that we should have a proper 
notif mechanism because sooner or later we will have several views for the 
same mailbox : filtered views or virtual folders are the good examples of 
that. So the idea is to implement this notification schema by using 
"MESSAGES_NEW", "MESSAGES_DELETE" LibBalsaMailbox messages. So all backend 
function adding new messages to a mailbox should then emit "MESSAGES_NEW" 
signal on the modified mailbox, and all funcs that want to delete messages 
should notify by emitting "MESSAGES_DELETE" on mailboxes (here there is 
implementation difference because we always add messages to one mailbox, 
but we can imagine that we delete messages from several ones at a time, so 
perhaps we should just emit several "MESSAGES_DELETE", one for each 
modified mailbox).
That way each object that represents [part of] a mailbox connects itself 
to the notification signals to catch up modification and stay up-to-date. 
This is mandatory for multiple views because user will be able to delete 
messages from one view and all others should refresh accordingly for 
I'll put a patch to give a basis to work/discuss one soon.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]