On Sat, 2003-10-18 at 03:05, Roberto Rosselli Del Turco wrote: > Il ven, 2003-10-17 alle 17:32, Jeffrey Stedfast ha scritto: > > On Fri, 2003-10-17 at 04:47, Roberto Rosselli Del Turco wrote: > > > > > > 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 :-) > > I will have to think about it ;) But that's a useful tip anyway, because > now I know I can reduce memory usage by getting rid of old stuff. > > How about an "Archive folder" (/"Archive message") function? Letting you > zip and store away in an "Archive" dir all that you don't need at hand > anymore. Then you could "Browse archived mail" by uncompressing archived > files in temporary folders, just in case you have to find that three > years old mail. Would be nice.
yea, we've got a feature request for this... however, this feature would not actually help reduce memory usage. Just to clear things up a bit, we don't load the mailboxes into RAM - we just load a summary into RAM for each mailbox (for local folders, we load the summaries for each folder but for IMAP we only load the summaries for folders which have been opened that session - at least this is how it works now, may change in the future) a summary consists of all the info we need for the message-list, so: subject, from, to/cc, date sent, date received, message-id, references, etc. > > > > 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? > > > > 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 :-) > > Actually, it does: you have to use gconf-editor and set a key to allow > for this feature, but it's definitely there and I use it all the time > (GNOME 2.4). The usability people never considered this a "bug", but as > a "power user" feature, so they've taken it away from normal > preferences. well, the usability bug was more "user accidently changes shortcut... oops, now how does he/she get it back?" since few (none?) of the gnome/gtk apps actually had a way to restore these, the user was simply SOL. > > When a shortcut consists of only one key on an en keyboard, but requires > two, possibly far away, keys on other keyboards, you can't but be > grateful for feature :) A pity bonobo menus don't support it. afaik, there is a plan for a application menu/toolbar editor for GNOME that will allow users to customise their toolbars/menus etc for applications using the bonobo ui elements. I have no idea what has become of this. > > > > 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. > > Well thanks, that's nice to know! But is this documented somewhere? > Didn't read about it in the current docs. probably check the manual. if you can't find it there, then please submit a bug report and we can have Aaron add docs for that. > > > > 3. Again on the subject of moving to the next unread message, using the > > > space bar should do just that (or at least move to the next message); > > > and when there aren't unread messages left, it would be nice to move to > > > the next folder (MM asks you if you want to do that, actually). > > > > this has been discussed and found to be counter-intuitive. space should > > scroll the message, but NOT jump to the next message. that behaviour > > would be extremely annoying to a lot of users (including myself, who > > *hates* that feature of mutt). > > Makes sense, just thought it could be useful as an alternative to a > double-key shortcut to new messages. > > > > 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. > > Agreed, but that's what happens. Instead of having this: > > Subject A - 2003-10-15 > Subject A - 2003-10-16 > Subject A - 2003-10-17 > Subject B - 2003-10-14 > Subject B - 2003-10-15 > Subject B - 2003-10-16 > Subject B - 2003-10-17 > Subject B - 2003-10-18 > > I get this: > > Subject B - 2003-10-17 > Subject B - 2003-10-18 > Subject A - 2003-10-15 > Subject A - 2003-10-16 > Subject A - 2003-10-17 > Subject B - 2003-10-14 > Subject B - 2003-10-15 > Subject B - 2003-10-16 > > however I fiddle with the settings. looks like you have threading turned on, plus reverse date sort along with the fact that the correspondent that sent "Subject B - 2003-10-17" is using a broken mailer that does not properly set the threading attributes. > > > > This is quite annoying and, in some ways, unpredictable (i.e. > > > in certain folders threads behave better than in others), is this a > > > problem specific to the last Evo releases? > > > > huh? no. likely a bug in the other clients you communicate with if > > anything. they probably aren't properly setting the threading headers. > > I'm not following you here: what do you mean with "the other clients"? I > just download emails from my POP server, Evolution is the client here. > Threading in the same folders works great using Messenger (don't know > about other clients). what I meant was the mail clients that your correspondents were using. *those* other clients are broken and are not setting either the References header and/or the In-Reply-To header. This is what breaks threading... see, the way threading works is that you look at the References (or In-Reply-To) header and see what the parent message(s) are. Jeff _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
