On Tue, 2002-04-09 at 09:47, Not Zed wrote: > On Tue, 2002-04-09 at 02:54, Frederic Vanneste wrote: > > First of all, kudos to the whole Ximian team for > > putting together this IMO excellent product. > > After some fiddling it became my client of choice > > and I haven't had any issues in months except > > for some 'closing' problems (Waiting for component > > to die -- ...) from time to time. > > Is it just busy, or really hung? Sometimes it could be busy for a long > time. If it has hung (most notably if the application isn't using any > cpu and the disk is idle, etc), a backtrace and bug report will help us > identify and fix it. >
OK... If you can tell me how to backtrace or where I can find info on how to do that I would be happy to help you guys out when it happens again. > > First proposal/request: > > I like the essential idea behind the workgroup/pim > > features, but I'd rather have a choice. Let me > > explain... I use evolution mainly because of its > > _great_ imap-handling, it's the first (gui) mua > > that really does everything I need and does it > > _right_! But I only use the calendar-thingy > > on one system, and I *know* there are a lot of > > people that rarely of never use the calendar/tasks > > features. The summary feature is a nice addition, > > but it's a not really something everyone *needs*, right? > > Don't get me wrong, I really like those features, on > > my main system they are all enabled, but what I mean > > is that these should be 'options/plugins/whatever'. > > I managed to get evolution run as an imap-client only, > > by renaming the oaf files, so they're not loaded on > > startup, but it would be really nice if there was a > > more 'clean' way of doing that. Because of the > > nice modularity in the code of evolution, I 'guess' > > that would not be such a major obstacle to overcome > > (correct me if I'm wrong here, I'm not much of > > a programmer...). > > The problem is, for example, if you receive a meeting request, the > mailer assumes the calendar component is available, and/or tries to > start it up to handle it. And because of the terribly slow startup > process, and to help with debugging, these things are just started all > the time. > OK. I can understand that, but what I really mean is that a lot of people will use evolution as a mail client and nothing more. I for one, will _never_ receive meeting requests at my home machines and I guess you know as good as I that the largest portion of users _will_ be home users. And in the exceptional case that I might receive a meeting request, I really wouldn't care of it took 10sec to start the calendar or give me a msg that I need to start the calendar. And these things should be enabled by default, I just would like a clean option to *not* start them... eg. evolution --no-calendar --no-summary This would be a really cool feature that I allways lacked in the ancient times when I used outlook, you have the same situation there. 80% of the windows users I know, work with outlook to read their mail, but maybe 5% uses the calendar features. I run evo now without calendar and summary, and disabled the shortcut bar. Well it's just the *perfect* mua if you ask me... You could realy reach a wider audience if you ask me, 'cause a lot of people want a mail-client, not 'bloatware' as _they_ call it (these are not my words, but a lot of people look at it that way). And I think the larger the userbase, the larger the feedback, the better the product gets... No? > > Second, it would be really nice if you get more > > control over the imap caching. I work in mechanical > > engineering and get a lot of large files in my > > mailbox. Header caching is a major feature, but > > I hate it that I have to manually delete all those > > mime-files from the cache... You must understand that > > if you read your mail on different systems, > > all those files (of sometimes a couple megs each) get > > cached in all those places, taking a couple of 100Megs on > > each system after a couple of weeks. > > It would really be nice if there was an option to purge > > the mime-cache on exit/command/... > > I agree. The cache isn't really a cache at all, it is just a > disk-backing that never seems to get cleared unless the folder becomes > invalid. > > The NNTP code has a better cache design, but it hasn't been integrated > into IMAP yet, and may not for a while because the existing code is a > little tightly integrated with the operation of imap. And .. a cache > clearing option isn't that easy to add because of abstraction (i.e. the > mailer doesn't know if the store its talking to even uses one, e.g. > local mail). > > I think the best way is to just cache the MIMEs during the session and keep the headers in permanent cache... But that's just my opinion... How do other people look at this??? Cheers, Frederic -- "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
