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: Sun, 2 Jun 2002 09:59:26 +0200
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
example.
I'll put a patch to give a basis to work/discuss one soon.
Bye
Manu
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]