Re: [Evolution-hackers] Patches to fix bug 311512
Hi Jeffrey Over on bugzilla for bug 311512 I've been proposing an approach for fixing the bug of new mail notifications... Jeffrey wrote: Karl: this is how we originally implemented this feature... I don't remember what all the problems were, but it's got at least these problems: - it won't work for folders other than Inbox - it won't work unless the user enables filtering for IMAP/MH/Maildir (aka Storage) account types. Yeah - those were among my fears of this approach. However, I still guess catching email 'as it comes into evolution' ought to be the right direction. A question about Imap (and other storage type) accounts: when a new mail appears on the server in a non-Inbox folder, how does Evolution detect its presence without either the user 'visiting' that folder (forcing Evo to do a quick re-sync) or the storage-server (e.g. the Imap server) 'pushing' the info to the client? More specifically, where in the code might I see this? Another completely alternative approach would, I guess, be to look at the various 'stand-alone' notification programmes that are out there (e.g. www.nongnu.org/mailnotify) Perhaps a case could be made for moving the 'notification functionality' out of evolution client completely and into a standalone sub-programme? Just more thoughts in search of a solution ... Karl ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] The recent camel-lite improvements
On Wed, 2007-02-07 at 21:40 +0100, Gilles Dartiguelongue wrote: It'd be nice to see the work for IDLE make it to mainline too. I would like to warn that the work for IDLE pulls nearly each and every change to the IMAP code with it, as a dependency. The IDLE work requires changes to dealing with expunges, changes to the camelstream type (it needs non-blocked reading, and with the current design of Camel there's also no other way to read the IDLE responses correctly), changes to the imap-command type and really significant changes to the locking of the IMAP provider's connection. It also enjoys the condstore support, a lot. As well as that it enjoys the rewrite of the imap_update_summary implementation. That's mostly because the index of each summary item must be exactly correct with the sequence on the IMAP mailbox. Imagine that not being in sync and a push happening on that sequence. A push like an expunge or a flags-update: the wrong message would be changed locally. That would be like a bug that the user experiences as data loss. So it really really has to be absolutely correct. This is also why extra checking has been put in place in both imap_summary_update, imap_rescan and the new imap_rescan_condstore implementation: it *HAS* to be correct As a developer myself, I'm totally pro pushing the changes to Evolu- tion's Mailer component. You would indeed have instant changes and even eventually incrementally filling up the folder-view while you are downloading the folder(this is possible, yes. Like Polymer .. yes). But from a stability point of view, it *would* most likely destabilize the product ... Evolution at this moment. And that is must likely not interesting for Novell. Am I wrong or right about this feeling of mine ? :-) I would, however, aid the person that gets my work into a RD branch of Evolution or whatever. Evolution, however, isn't *my* focus project. And this would consume my entire own focus. I will help the person who makes it his project. That's what these notes are about. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Patches in need of review (E-D-S)
Following up on the list I made for Evolution. This time e-d-s: Bug 363102 – E-D-S crash (and potential data corruption?) due to thread race condition http://bugzilla.gnome.org/show_bug.cgi?id=363102 Bug 359806 – Non-ascii characters generate trash in address lists http://bugzilla.gnome.org/show_bug.cgi?id=359806 Bug 384044 – possible memory leak in icalvalue_decode_ical_string http://bugzilla.gnome.org/show_bug.cgi?id=384044 Bug 394567: ical file ends \r\n and fbtypes http://bugzilla.gnome.org/show_bug.cgi?id=394567 Bug 331099: evolution allocates 65GB of memory then pages to death on amd64 http://bugzilla.gnome.org/show_bug.cgi?id=331099 Bug 360807: Memory leak when using SMTP AUTH http://bugzilla.gnome.org/show_bug.cgi?id=360807 Bug 373495: e-d-s doesn't honor prefix http://bugzilla.gnome.org/show_bug.cgi?id=373495 Bug 400629: EDS fails to distcheck http://bugzilla.gnome.org/show_bug.cgi?id=400629 There are lots more that are fairly easy patches to optimize stuff or clean up code, but I think those should be secondary to the more serious issues like crashes and stuff not building etc. Cheers Kjartan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Where to put UI items for templates (Bug #127529)
On Thu, 2007-02-15 at 23:22 +0100, guenther wrote:
On Tue, 2007-02-13 at 21:05 +0530, Sankar P wrote:
On Fri, 2007-01-26 at 16:59 -0600, Matthew Martin wrote:
I need to know where to put all
the UI items for templates. There would need to be a save template,
default new mail, and default reply items. I read some of the HIG and
stuck them in there so I could write the code. Here's a link to the
patches. http://mtt.martin.googlepages.com/ The first one is for
evolution, and the second is for evolution-data-server.
I had a look at the patch in the above url and some things that I found
on an first-look are:
The Template should be singleton and each account may not have a
separate template folder. (Should be like Outbox)
I'm not sure I agree here.
Still pondering, but... We offer per account Drafts folders. And I don't
yet see, why either one should be limited to a single, particular
machine in a, say, IMAP environment. Sent is not. Drafts is not. Why
should Templates be?
Based on this approach, I believe it actually should be per account,
being configurable exactly like the other default folders. Also, this
UI part should go there.
After all, Templates are Drafts that do not delete them selves, right?
Whatever we store under Templates are not completely formed messages.
They will not have any sender/recipient that a basic mail will have.
Also it will contain things like ${DATE}, ${me},
Reference-to-a-SIGNATURE-FILE, which takes some special interpretation
that is specific to Evolution alone.
Overall, it is just Evolution that can make meaning out of a thing that
is stored as a template in Evolution. It may not be of any use to other
mail clients. So, I do not see any benefit by putting it in the server.
It is more like Signatures that are specific to Evolution and are stored
locally in Evolution.
What will be really useful will be to have Names for these templates and
we can associate a default template for an account (Again like
signatures). These names can be used to choose, from New from Template
dialog as well; Like OO templates-choosing dialog.
guenther
--
Sankar
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
