+
+ MODEST_DEBUG_BLOCK (print_queue_item (mail_op, "add"););
+
+ /* Get notified when the operation ends to remove it from the
+ queue. We connect it using the *after* because we want to
+ let the other handlers for the finish function happen
+ before this */
+ g_signal_connect_after (G_OBJECT (mail_op),
+ "operation-finished",
+ G_CALLBACK (on_operation_finished),
+ self);
+
+ /* Notify observers */
+ g_signal_emit (self, signals[QUEUE_CHANGED_SIGNAL], 0,
+ mail_op, MODEST_MAIL_OPERATION_QUEUE_OPERATION_ADDED);
+}
+
+static gboolean
+notify_queue_empty (gpointer user_data)
+{
+ ModestMailOperationQueue *self = (ModestMailOperationQueue *) user_data;
+ ModestMailOperationQueuePrivate *priv;
+ guint num_elements;
+
+ priv = MODEST_MAIL_OPERATION_QUEUE_GET_PRIVATE(self);
+
+ g_mutex_lock (priv->queue_lock);
+ num_elements = priv->op_queue->length;
+ g_mutex_unlock (priv->queue_lock);
+
+ /* We re-check again that the queue is empty. It could happen
+ that we had issued a tny_send_queue_flush before the send
+ queue could add a mail operation to the queue as a response
+ to the "start-queue" signal, because that signal is issued
+ by tinymail in the main loop. Therefor it could happen that
+ we emit the queue-empty signal while a send-queue is still
+ waiting for the "start-queue" signal from tinymail, so the
+ send queue will never try to send the items because modest
+ is finalized before */
+ if (num_elements == 0) {
+ gdk_threads_enter ();
+ g_signal_emit (self, signals[QUEUE_EMPTY_SIGNAL], 0);
+ gdk_threads_leave ();
+ }
+
+ return FALSE;