Re: [Evolution] User impressions about Evolution

1. I noticed that Evo is fast, really faster than MM on my 2200 Athlon
box; memory usage, OTOH, is much higher than I expected/remembered: is
it normal to reach 60Mb? why does it seem to increase with time?
Fortunately I have plenty of memory, but it was a mild shock noticing
that Evo starts a session with about 31-2 megs (in itself much more than
I remembered) and it might end up with almost 60 MB: is this related to
the amount of mails stored in the database?

yes. you're complaining about 60 megabytes? that's nothing. the more
mail you have, the more memory evolution uses. we do as much as we
reasonably can to keep memory usage down such as using string pools,
memory chunks, shared ref-counted objects, etc. If you know of a way to
make it use less memory, feel free to tell us about this new trick :-)

Using vFolders on large mail folders can be a real hog, AFAIK...

2. The UI is OK, or I'm getting used to it (waiting for Evo 2.0), but
there are some quirks: why can't I change accelerators/shortcuts as with
other GNOME apps?

Well, there is no way for the user to do it -- but you can change any
shortcut (and even quite a lot more) in the XML files that define them.
See /usr/share/evolution/1.4/ui/ for the files. I have mentioned this
with practical usages sometimes, so you even can find examples in the

because the bonobo menu items don't allow it. only gtk menus allow it,
and that was considered a bug. I don't think gtk2.0 allows this anymore.
(Nope, it doesn't. Just checked :-)

 f.i. I just had the habit to press N to go to the next
unread message, with Evo it's a rather unintuitive ], and I have to
press two keys; so I'd like to change the shortcut, but it seems to be

just use , and . - only 1 key.

...or redefine them.

4. Threads aren't displayed very well: messages that should belong to
the same thread are dispersed according to their date in many different

huh? we thread according to in-reply-to and references headers. we don't
thread based on date. this makes no sense.

Threading is perfect. I wrote more about this recently:

5. Another (minor) issue with threads: the grey/white line coloring is
great when order messages without threading, but is slightly confusing
when you use threads; it would be nice to differentiate between
differents threads alternating white for *all* messages that belong to a
thread, grey for all those that belong to the next one, and so on. Don't
know if the text widget allows this.

Well, you would like this, I would actually hate this. ;-)

*shrug* might be a good idea. no one has ever suggested this before
afaik, perhaps submit it as a feature request for the GAL::ETree widget.

Optional would be fine.

6. One last note about threads (I promise :) : add a "Mark all as read
in thread" command, would be a real time saver.

Edit->Select Thread
Edit->Mark As Read

Ctrl-H Ctrl-K

8. Import routines have their own quirks, for instance I had to import
manually all of my Mozilla folders because only Pine (?) was listed in
the "general" import dialog; and when importing Mozilla addressbooks, I
had to specify the format once or twice, because it wasn't recognized

A hint on importing: If you have a folder, where you want to import mail
into, you even can use drag-n-drop. Drag the mbox file and drop it over
a mail folder. (This is actually a move operation, rather than copy.)

9. Why is a HTML commands tool bar present in the mail composing window
even if I chose to not compose mails in HTML format?

because it still has some tools that are useful even in plain text

Paragraph style Normal/Preformat is really useful, even when indent and
center text on your own. ;-)


char *t="\10pse\0r\0dtu\0  ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

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