Re: Libmailcheck- take two

[Miguel de Icaza <miguel nuclecu unam mx>]

> I might put two mailcheck applets on my panel, one 
> configured to use an audio alarm, and the other silent.  I would set 
> the audible one to alert me to new mail in my personal inbox folder 
> or gnome-announce, for example, while telling the silent one to 
> monitor mail to gnome-devel and gnome-list, which I don't want to be 
> disturbed with by frequent alarms.

I do think that the way you get notifications about mail is not
something that must be addressed by the libmailcheck.

Further, I think the mail checking object should not have a notion of
Mail sets.

The Mail sets is something that will require a GUI to configure and
the program could use the simpler to use method of just creating one
object per mail-input source to monitor and bind each one accordingly.

The GUI will do the bindings:

    gnome-list       -> signal_connect (silent notification)
    gnome-devel-list -> signal_connect (silent_notification)
    personal-mail    -> signal_connect (beep_all_over_the_place)
    gnome-announce   -> signal_connect (carrot_display)

> they would each have their own registration function, which could
> potentially accept whatever parameters they needed (hostname,
> username, password, etc).

Sounds good.  

Now, I do suggest that we do not implement various gtk-level objects
for each method, as we want a corba server to actually take care of
the task, so we would have a unified creation routine:

gnome_mailcheck_new (char *descriptor)

Where the descriptor would be a string that identifies the protocol
and then protocol-specific data, like this:

    "unix:/var/spool/mail/miguel"
    "pop3:miguel:password@mailserver.unam.mx"
    "imap:yadayada"

The actual modules could even be shared libraries loaded on demand,
which solves the registration issue from the C-land. 

> (The suggestion to use fetchmail is intriguing, since it would remove 
> a good deal of code from the library which is already written better 
> than I could hope to.  But do we want to rely on it from inside of 
> gnome-libs?  I don't know enough about the architecture of the rest 
> of the GNOME libraries to know if that's a problem...)

Mhm, my impression was that we were going to have a CORBA server do
this.   If we use a CORBA server the stuff in the libmailcheck library
would only be calling the CORBA server and registering a notification
server on this end to get notifications.

When you want to stop getting events for a mail source, you just need
to gtk_object_unref the object you created.  The finalize method
should take care of notifying the CORBA server.

Now, the notification issues: instead of using a new notification
mechanism, I suggest you use regular GTK signals, so that the client
code can attach in any way it wants.

So, you class declaration would look like this:

typedef struct {
	GtkObject base_object;

	...
} GnomeMailCheck;

typede struct {
        GtkObjectClass parent_class;

	void (*mail_notify)(char *descriptor, int messages, int new_messages);
} GnomeMailCheckClass

That way, any number of routines can be hooked by using:

     gtk_signal_connect (GTK_OBJECT (mailbox), "mail_notify", 
                         GTK_SIGNAL_FUNC(my_notificayion_function), ...);


Miguel