On Sat, 2005-04-02 at 09:54 +0800, Not Zed wrote: > > Hi Lee, > > Well, many of the mail ones not marked as complete are almost complete > or it is just paperwork that they're not. > > e.g. mail notification applet is basically done (via dbus stuff) > inling pgp is being worked on (i think) > default mail app is just waiting for copyright assignment forms from > beruit > message disposition notification is just waiting for a couple of minor > cleanups but is basically done > > The message templates would be a nice feature. It would be > interesting if it could be done as a plugin - i.e. first a plugin hook > needs to be written to give access to the editor at the right time, > etc, then the plugin to actually implement it. It *may* be possible > to do this using the existing hooks, certainly a first-cut should be > able to get at least something working for this, even if it isn't > ideal. > > It would be good to see if the plugin system is flexible enough to do > it for a start, and then it would probably be a good place to look at > lots of mailer-related code to do it. >
Thanks, I'll look at this one. > If you have other interesting ideas they may be worth looking into > too. e.g. a backup tool would be nice, that exported all data into a > versioned format/file, that could later be imported into this or other > versions of evolution. Some people have looked at various > incarnations of this, but they mostly rely on nothing more than > tarring up the files so far, or they don't backup configuration data. > There are many other possibilities I am sure. Well, if I weren't doing this for the money (or if there were a bounty for it) the first thing I would fix is to make the "Unread Mail" vfolder usable on a slower machine when there are thousands of unread messages. This has been bugging me since at least 2.0. I looked at it briefly, and all I can tell from oprofile is that a lot of time is being spent somewhere in libcamel, but didn't get much farther as I did not have a debug build of that library available. In general I found 2.2 to be a big performance improvement over 2.0, except for this issue. Another idea that Robert Love has mentioned several times on LKML is a mechanism to catch so-called -ENOPATCH user errors. The simplest imaginable form would run the outgoing message through patch(1) and check for a nonzero return value when it sees [PATCH] in the subject line. Eventually it could use a better heuristic to tell when the user meant to send a patch. Lee _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
