[Evolution-hackers] Evolution slowing down

[Karl Relton]

Hi all

Is it just me, or is evolution 3.6 now really slow. I find opening and
closing message windows markedly slower than 3.2 on the same hardware.

Even worse, the slowness gets worse with usage - so after a day's usage
it is pretty intolerable (to the point where the window manager kicks in
thinking the application is unresponsive).

I'm guessing it is the move to webkit or whatever for viewing messages?
The slowness is obvservable for both reading a message and composing a
message.

Anyone else seen this?

Karl

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Please comment on patch for evolution contacts access in deskbar-applet

[Karl Relton]

Hi friends

The deskbar-applet utility uses e-d-s to search through evo
addressbooks. However the code used wasn't working on evo-ldap
addressbooks.

On investigation, I found the code was using e_book_new_from_uri when it
could have simply been using e_book_new. Changing as per the attached
patch fixes the problem.

The maintainer of deskbar applet would like an Evo guru to just give a
nod or thumbs up that this makes sense, before he commits.

Can someone please take a look - I've included the whole function in the
2nd attachment to give the overall context.

Thanks
Karl
--- evolution.c.orig	2007-08-02 21:45:02.0 +0100
+++ evolution.c	2007-08-02 21:47:14.0 +0100
@@ -215,13 +215,11 @@ init (void)
 			p = e_source_get_property (source, completion);
 
 			if (p != NULL  strcmp (p, true) == 0) {
-char *uri = g_strdup_printf (%s/%s, e_source_group_peek_base_uri (group), e_source_peek_relative_uri (source));
-EBook *book = e_book_new_from_uri (uri, NULL);
+EBook *book = e_book_new (source, NULL);
 if (book != NULL) {
 	books = g_slist_prepend (books, book);
 	e_book_open(book, TRUE, NULL);
 }
-g_free (uri);
 			}
 		}
 	}

void
init (void)
{
	GSList *list, *l;
	ESourceList *source_list;

	source_list = e_source_list_new_for_gconf_default (/apps/evolution/addressbook/sources);
	if (source_list == NULL) {
		return;
	}

	list = e_source_list_peek_groups (source_list);

	for (l = list; l != NULL; l = l-next) {
		ESourceGroup *group = l-data;
		GSList *sources = NULL, *m;
		sources = e_source_group_peek_sources (group);
		for (m = sources; m != NULL; m = m-next) {
			ESource *source = m-data;
			const char *p;

			p = e_source_get_property (source, completion);

			if (p != NULL  strcmp (p, true) == 0) {
EBook *book = e_book_new (source, NULL);
if (book != NULL) {
	books = g_slist_prepend (books, book);
	e_book_open(book, TRUE, NULL);
}
			}
		}
	}

	g_object_unref (source_list);
}
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Proposed fix for bug 311512

[Karl Relton]

Hi friends

I have submitted new patches to bugzilla for bug

http://bugzilla.gnome.org/show_bug.cgi?id=311512


One changes e-d-s as Fejj suggested, the other does the Evolution side
so it will only do mail-notification on 'truely' new messages.

I'll be pleased if you could review.

Karl


On Thu, 2007-04-26 at 09:29 -0400, Jeffrey Stedfast wrote:
 not completely correct... 
 
 when you trigger an event on a CamelObject, it first fires the prep
 callback, which is what camel-folder.c:folder_changed() is (note that it
 returns bool)
 
 A prep event handler is the first handler called (event handlers are
 fired sequentially, in order of connection - /not/ in parallel) and gets
 to decide if the event propagates by returning TRUE (or FALSE if it
 should be blocked - that's how freeze/thaw works).
 


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Proposed fix for bug 311512

[Karl Relton]

On Thu, 2007-04-26 at 09:29 -0400, Jeffrey Stedfast wrote:
  Yes - I had thought of this too.
  
  The trouble is with the current code its not quite so simple AFAIK. The
  filtering that takes place is actually launched from the
  folder_changed() function in camel-folder.c. In other words, it is
  launched from the folder_changed event handler itself. Now I may be
  wrong here, but my assumption is that both evo and e-d-s register event
  handlers on this type of event - so that when such an event occurs code
  in both evo and e-d-s is executed ... perhaps even in parallel (in their
  own threads)?
 
 not completely correct... 
 
 when you trigger an event on a CamelObject, it first fires the prep
 callback, which is what camel-folder.c:folder_changed() is (note that it
 returns bool)
 
 A prep event handler is the first handler called (event handlers are
 fired sequentially, in order of connection - /not/ in parallel) and gets
 to decide if the event propagates by returning TRUE (or FALSE if it
 should be blocked - that's how freeze/thaw works).
 
  
  If this is the case, then it is effectively too late to 'trap' the
  event, because evo will already be processing it.
 
 all the event handler has to do is return FALSE to block other event
 handlers from firing :)
 
   Thus (AFAICS) even if
  camel is in a 'freeze' for folder_changed events, evo will still be
  firing on every folder_changed occurence.
 
 only if folder_changed() returns TRUE - folder_changed() is what checks
 if the folder is in a freeze state, and if it is blocks further events
 from firing (by returning FALSE).
 
 You have da powah!
 
  
  One way to solve that would be to change things so that evo only fires
  when camel folder_changed stuff has really done: effectively at the end
  of a freeze AND filtering. That could be done by introducing a new event
  and making evo trigger off that perhaps?
 
 unnecessary. all the tools are already available :)
 

Excellent - many thanks for correcting me on my understanding. I'll look
into it more to see how this can be worked up. Give me a couple of
weeks, and I'll come back if I find I need more understanding.

Karl

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Proposed fix for bug 311512

[Karl Relton]

Matthew

As a new Mail maintainer, could you take a look at my proposed patches
for fixing bug 311512. Srini has had a look, and noted the ABI breakage
(see below). This was deliberate on my part - the only way to get
newmail notification to take note of the results of a filter thread.

Many thanks
Karl

On Fri, 2007-03-30 at 12:43 +0530, Srinivasa Ragavan wrote:
 On Fri, 2007-03-30 at 07:51 +0100, Karl Relton wrote:
  Last week I posted two patches (one for eds, one for evo) on evo bugzill
  that I believe fix bug 311512.
 
  --- camel-folder.h.110  2007-03-20 16:57:40.0 +
  +++ camel-folder.h  2007-03-20 16:50:34.0 +
  @@ -195,6 +195,7 @@ typedef struct {
  void (*freeze)(CamelFolder *folder);
  void (*thaw)  (CamelFolder *folder);
  gboolean (*is_frozen) (CamelFolder *folder);
  +   int  (*get_filter_thread) (CamelFolder *folder);
   } CamelFolderClass;
 
 On first look, I noticed that your patch has introduced an ABI break in
 CamelFolderClass. 
 
 I'm sure that the mailer hackers would have a more closer look at it. 
 
 Thanks for your friendly poke :-) 
 
 -Srini.
 
  f
  Could you take a look - any comments are welcome!
  


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Bug in main_system_beep?

[Karl Relton]

On Fri, 2007-03-30 at 12:34 +0530, Srinivasa Ragavan wrote:

  Whilst looking at the code for other things, I think I have spotted a
  bug in main_system_beep() in mail-session.c.
 You are absolutely right. It is a bug and the patch fixes it right. Just
 for tracking, file a bug and attach the patch to bugzilla (Pass us the
 bug id). It has to go for STABLE and trunk branches.
 

Bug id 424795.

I'm not sure what you mean by 'It has to go for STABLE and trunk
branches', I'll leave that to you.

Regards
Karl

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Bug in main_system_beep?

[Karl Relton]

Srini

Welcome to your new role. I posted this on evolution-patches a couple of
weeks back, but  don't think anyone has got round to it yet ...


Whilst looking at the code for other things, I think I have spotted a
bug in main_system_beep() in mail-session.c.

Comparing the beep function with play_sound function:

session_play_sound() and main_play_sound() do a
camel_object_ref(session) and a camel_object_unref(session) between
them.

However, session_system_beep() and main_system_beep() does the
camel_object_ref(session) but without the corresponding unref.

I assume thats wrong - the  patch below fixes that by putting in the
unref.

Karl

--- mail-session.c.old  2007-03-02 11:31:23.0 +
+++ mail-session.c  2007-03-02 11:29:42.0 +
@@ -441,6 +441,7 @@ static void
 main_system_beep (CamelFilterDriver *driver, gpointer user_data)
 {
gdk_beep ();
+   camel_object_unref (session);
 }
 
 static void


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Proposed fix for bug 311512

[Karl Relton]

Srini

Welcome to your new role (again!).

Last week I posted two patches (one for eds, one for evo) on evo bugzill
that I believe fix bug 311512.

Could you take a look - any comments are welcome!

Regards
Karl

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Another approach for bug 311512

[Karl Relton]

Hi all

Having not found a satisfactory solution to bug 311512 (new mail
notification) by trying to put the notification code into where mail is
received by the camel backends, I've looked into a different approach.

I was intrigued by how the mail-notification tool works, since it
effectively hangs off the same problematic folder.changed event. Looking
at its source code revealed that the author added to code to 'snoop'
through the messages, looking for ones that really were newmail (rather
than simply 'added to this folder').

So I have replicated this approach, but natively in evolution. The
attached patch affects mail-folder-cache.c only, and adds a function to
look for new messages comparing their 'received' timestamp with a global
timestamp. This enables us to check for messages that are brand new -
received since the last new mail arrived.

Can anyone comment on this patch - it should resolve nearly all the mail
notification problems. The one is doesn't resolve is to do with junk
mail - presumably I can just add a test against the messages to see if
they are junk. However - that assumes no folder_changed call happens
until after the junk-mail filtering has happened.

Currently the check has to snoop all messages in the folder. I think in
principle I can move the test into folder_changed and snoop through the
list of 'uid_added', which should be more efficient. Assuming nobody
flags any big pitfalls, I'll look into that soon.

Regards
Karl
--- mail-folder-cache.h.old	2007-03-02 13:11:50.0 +
+++ mail-folder-cache.h	2007-03-02 11:49:43.0 +
@@ -25,6 +25,9 @@
 #ifndef _MAIL_FOLDER_CACHE_H
 #define _MAIL_FOLDER_CACHE_H
 
+/* min no. seconds between newmail notifications */
+#define NOTIFY_THROTTLE 30
+
 #include camel/camel-store.h
 
 /* Add a store whose folders should appear in the shell
--- mail-folder-cache.c.old	2007-03-02 13:11:42.0 +
+++ mail-folder-cache.c	2007-03-02 13:14:13.0 +
@@ -103,7 +103,8 @@ struct _folder_update {
 	char *olduri;
 
 	int unread;
-	CamelStore *store;
+CamelStore *store;
+CamelFolder *folder;
 };
 
 struct _store_info {
@@ -127,10 +128,10 @@ static guint notify_id = 0;
 static int notify_type = -1;
 
 static time_t last_notify = 0;
+static time_t last_newmail = 0;
 static guint notify_idle_id = 0;
 static gboolean notify_idle_cb (gpointer user_data);
 
-
 /* Store to storeinfo table, active stores */
 static GHashTable *stores = NULL;
 
@@ -191,14 +192,41 @@ notify_type_changed (GConfClient *client
 	notify_type = gconf_client_get_int (client, /apps/evolution/mail/notify/type, NULL);
 }
 
+static gboolean
+check_brand_new(CamelFolder *folder)
+{
+GPtrArray *summary;
+int i;
+
+summary = camel_folder_get_summary(folder);
+for (i = 0; i  summary-len; i++)
+{
+	CamelMessageInfo *info = summary-pdata[i];
+
+//	Check junk here using the flags?
+	if (((camel_message_info_flags(info)  CAMEL_MESSAGE_SEEN) == 0) 
+		 (camel_message_info_date_received(info)  last_newmail))
+	{
+		camel_folder_free_summary(folder, summary);
+		time (last_newmail);
+		d(printf(brand_new TRUE\n));
+		return TRUE;
+	}
+}
+
+camel_folder_free_summary(folder, summary);
+	d(printf(brand_new FALSE\n));
+return FALSE;
+}
+
 static void
 real_flush_updates(void *o, void *event_data, void *data)
 {
 	struct _MailComponent *component;
 	struct _EMFolderTreeModel *model;
 	struct _folder_update *up;
-	time_t now;
-	
+gboolean brand_new = FALSE;
+
 	component = mail_component_peek ();
 	model = mail_component_peek_tree_model (component);
 	
@@ -230,7 +258,12 @@ real_flush_updates(void *o, void *event_
 		
 		/* update unread counts */
 		em_folder_tree_model_set_unread_count (model, up-store, up-full_name, up-unread);
-		
+	
+	/* Check for brand new mail */
+	if (up-new  up-unread  0) {
+		brand_new = check_brand_new (up-folder);
+		}
+	
 		/* new mail notification */
 		if (notify_type == -1) {
 			/* need to track the user's new-mail-notification settings... */
@@ -244,13 +277,12 @@ real_flush_updates(void *o, void *event_
 			notify_type = gconf_client_get_int (gconf, /apps/evolution/mail/notify/type, NULL);
 		}
 		
-		time (now);
-		if (notify_type != 0  up-new  notify_idle_id == 0  (now - last_notify = 5))
+		if (notify_type != 0  brand_new  notify_idle_id == 0  (last_newmail - last_notify = NOTIFY_THROTTLE))
 			notify_idle_id = g_idle_add_full (G_PRIORITY_LOW, notify_idle_cb, NULL, NULL);
 		
 		if (up-uri) {
 			EMEvent *e = em_event_peek();
-			EMEventTargetFolder *t = em_event_target_new_folder(e, up-uri, up-new?EM_EVENT_FOLDER_NEWMAIL:0);
+			EMEventTargetFolder *t = em_event_target_new_folder(e, up-uri, brand_new?EM_EVENT_FOLDER_NEWMAIL:0);
 
 			/** @Event: folder.changed
 			 * @Title: Folder changed
@@ -380,6 +412,7 @@ update_1folder(struct _folder_info *mfi,
 	up-new = new ? 1 : 0;
 	up-store = 

Re: [Evolution-hackers] Patches to fix bug 311512

[Karl Relton]

Hi Jeffrey


Over on bugzilla for bug 311512 I've been proposing an approach for
fixing the bug of new mail notifications...

Jeffrey wrote:
 Karl: this is how we originally implemented this feature... I don't remember
 what all the problems were, but it's got at least these problems:
 
 - it won't work for folders other than Inbox
 
 - it won't work unless the user enables filtering for IMAP/MH/Maildir (aka
 Storage) account types.

Yeah - those were among my fears of this approach. However, I still guess 
catching
email 'as it comes into evolution' ought to be the right direction.

A question about Imap (and other storage type) accounts: when a new mail appears
on the server in a non-Inbox folder, how does Evolution detect its presence 
without
either the user 'visiting' that folder (forcing Evo to do a quick re-sync) or 
the
storage-server (e.g. the Imap server) 'pushing' the info to the client?

More specifically, where in the code might I see this?


Another completely alternative approach would, I guess, be to look at the 
various
'stand-alone' notification programmes that are out there (e.g. 
www.nongnu.org/mailnotify)
Perhaps a case could be made for moving the 'notification functionality' out of
evolution client completely and into a standalone sub-programme?


Just more thoughts in search of a solution ...
Karl

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Mail-Notifier

[Karl Relton]

 Hi, 
 
 My first post in the list ;-)
 
 I've done a very little app in python and GTK than could be useful as
 an
 Evolution add-on or plug-in, it's a mail-notifier using Evo's DBus
 messages. 
 
 You can download the source code here
 http://www.kalpe.com/?section=mail_notifier
 
 I hope you'll find it interesting...
 
 Quim

Quim

Welcome to the list.

You may not know, but there is already some basic c code known as
em_panel_applet out on the internet that does the same thing - although
it doesn't use the notification library to produce a popup. This code
was written as a sample tray applet for new mail notification - but
being only a sample never seemed to make it mainstream or get
integrated/packaged by anybody.

Note that evolution has reported bugs regarding sending the NewMail
messages over dbus: see bugzilla.gnome.org/show_bug.cgi?id=311512

This has some relationship to your problem of showing the icon.
Personally though, I prefer your option #2 anyway - i.e. only show the
icon when 'unseen' newmail has arrived, and hide it as soon as the user
reads at least one message. That is my personal preference though -
others may prefer different solutions - ultimately it may be something
users want configurable.

Karl

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers