> > 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 archives. > 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 > > impossible. > > 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 > > threads. > > 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: http://lists.ximian.com/archives/public/evolution/2003-October/033108.html > > 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 > > automatically. 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 > formatting. Paragraph style Normal/Preformat is really useful, even when indent and center text on your own. ;-) ...guenther -- char *t="[EMAIL PROTECTED]"; 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; }}} _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
