Re: [Evolution-hackers] EWS: refresh your calendar cache
On Wed, 2011-03-02 at 08:11 -0500, Matthew Barnes wrote: Also, I'd encourage developers to post the occasional status update to the list. Nothing formal, and at your own discretion. This is probably a good enough time for us to do that for evo-ews. If you clone the tree from git://git.infradead.org/evolution-ews.git then you should be able to build it on a stock Evolution 2.32 system (for example Fedora 14) and use it against an Exchange 2007+ server. It's working nicely in read-only mode and I've been doing that to read all my company email for the last few weeks, and can view my company calendar that way too. There are two things I think need fixing before I'd really suggest that people use it 'in anger', but which aren't *really* showstoppers: - Tell the server about messages having been read, so they don't appear as unread in IMAP/Outlook. And deletion too, I suppose. - Make it handle 'variance' of recurring meetings — for example if a single instance of a recurring meeting is deleted, or rescheduled. We don't show those exceptions yet. It also doesn't let you send mail yet; I'm still using SMTP for that (and IMAP for writing the Fcc to the mail store). But for someone who wants to be an 'early adopter' and try it, it's certainly feasible right now. Even if you just look at the things we *think* we've done, and heckle when we've got things wrong, that's still useful. -- dwmw2 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Beware of GtkTreeRowReference
On Wed, 2011-03-02 at 15:19 +0100, Milan Crha wrote: Not enough, because the above. I'm doing this [1] (2.91.91+). Search for e_attachment_store_remove_all() calls (the patch fixes also placing of attachments to the correct bar). That works, I guess. In other places were I build a hash table index for a model (I've been using this pattern for awhile so there's probably quite a few places), a custom e_whatever_clear() function could clear both the hash table and the model. It's a shame GtkListStoreClass/GtkTreeStoreClass doesn't have a clear() method for subclasses to override. That would at least give us a hook for dealing with this without having to write our own function. You might use something less aggressive, like iterator or path, for local indexes. Won't work in the general case. As soon as you insert or delete a row prior to the row you're tracking, GtkTreeIter and GtkTreePath are both invalid. That's why GtkTreeRowReference exists. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Beware of GtkTreeRowReference
On Wed, 2011-03-02 at 09:36 -0500, Matthew Barnes wrote: You might use something less aggressive, like iterator or path, for local indexes. Won't work in the general case. As soon as you insert or delete a row prior to the row you're tracking, GtkTreeIter and GtkTreePath are both invalid. That's why GtkTreeRowReference exists. Actually I might be wrong about iterators for GtkListStore. GtkListStore uses a GSequence internally, and it stores a GSequenceIter in the GtkTreeIter.user_data field. GSequenceIter is supposedly stable; it remains valid even after the GSequence is sorted. So maybe GtkTreeIters -would- work for the hash table index using gtk_tree_iter_copy() and gtk_tree_iter_free(). I'll do some further testing to verify. Again this would only work for GtkListStore, but that still covers the majority of cases if I recall correctly. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
