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
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 08:37 -0500, Matthew Barnes wrote: > Does GtkTreeRowReference drop its model reference when the row is > removed? Hi, it unrefs model when itself is freed, not the row itself (thus the validity check on the reference, I suppose). > If so, it ought to be sufficient to clear the model with > gtk_list_store_clear() or gtk_tree_store_clear() before unreffing it. > Is that what you're doing? 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). You might use something less "aggressive", like iterator or path, for local indexes. Bye, Milan [1] http://git.gnome.org/browse/evolution/commit?id=2533e52 ___ 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] 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
[[I'm CC'ing the hackers list.]] On Wed, 2011-03-02 at 14:00 +0100, Milan Crha wrote: > The GtkTreeRowReference is adding a reference count to the model, so if > you store this GtkTreeRowReference inside model itself, then the model > is never freed. This is a case for EAttachmentStore, if it has some > attachments, then it's never freed, same as the inner object and the > CamelMimePart and god knows what else. That might explain increasing > memory usage in evolution when have run it for few hours. I'm finishing > a patch for this in git master, it's under testing right now, but I > wanted to warn you, because this circular dependency is not obvious on > the first look. Please avoid similar approaches in the future. > > I'm not removing this GtkTreeRowReference from the EAttachment, I'm only > making sure when the object whom created EAttachmentStore also removes > all attachments before it unrefs the store itself - basically because > it's too late for any bigger kick into sources. Huh, thanks for the tip. That's probably an issue in several other places in Evolution and libedataserverui then. Whenever I subclass GtkListStore or GtkTreeStore I usually build an internal index of whatever would be the primary key in the store, and I do that with a hash table of GtkTreeRowReferences. Does GtkTreeRowReference drop its model reference when the row is removed? If so, it ought to be sufficient to clear the model with gtk_list_store_clear() or gtk_tree_store_clear() before unreffing it. Is that what you're doing? ___ 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] EWS: refresh your calendar cache
On Wed, 2011-03-02 at 12:54 +, David Woodhouse wrote: > ( > Preface: rather than continuing to use private mail, I'd like to start > using a proper mailing list for people working on our Exchange Web > Services plugin. I thought briefly about setting up a new list, but > decided that the evo-hackers list was probably a better place. > > I think it's useful to work "in the open" rather than having each team > who are working on a plugin do so in their own private list without us > all talking to each other and being aware of what's going on elsewhere. > > If anyone really objects to ususing the evo-hackers list for this > purpose, please say so, and we'll consider switching to a new list > for evo-ews. I'd rather not do that, though. > ) > Yup! I was wondering the same. :) //Johnny ___ 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] EWS: refresh your calendar cache
On Wed, 2011-03-02 at 12:54 +, David Woodhouse wrote: > ( > Preface: rather than continuing to use private mail, I'd like to start > using a proper mailing list for people working on our Exchange Web > Services plugin. I thought briefly about setting up a new list, but > decided that the evo-hackers list was probably a better place. > > I think it's useful to work "in the open" rather than having each team > who are working on a plugin do so in their own private list without us > all talking to each other and being aware of what's going on elsewhere. > > If anyone really objects to ususing the evo-hackers list for this > purpose, please say so, and we'll consider switching to a new list > for evo-ews. I'd rather not do that, though. > ) +1! That's exactly what the mailing list is for. Also, I'd encourage developers to post the occasional status update to the list. Nothing formal, and at your own discretion. Just kinda like what I've been doing with the "Rethinking account management" thread. Like blogging but to a more targeted audience. The monthly meetings are not frequent enough for me to keep tabs on what you guys are up to, and round-robin status updates in an IRC channel are not a good forum for going into any kind of detail. Use the list! ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] EWS: refresh your calendar cache
( Preface: rather than continuing to use private mail, I'd like to start using a proper mailing list for people working on our Exchange Web Services plugin. I thought briefly about setting up a new list, but decided that the evo-hackers list was probably a better place. I think it's useful to work "in the open" rather than having each team who are working on a plugin do so in their own private list without us all talking to each other and being aware of what's going on elsewhere. If anyone really objects to ususing the evo-hackers list for this purpose, please say so, and we'll consider switching to a new list for evo-ews. I'd rather not do that, though. ) I've just added code to include an X-EVOLUTION-CHANGEKEY property in calendar items fetched from EWS. This is required for any subsequent modification to those items. You'll need to throw away your calendar cache and let it get refetched: rm -rf ~/.cache/evolution/calendar/ews* Then you should find that at least discarding alarms should work. If you have killed e-calendar-factory and you're running it from a terminal with EWS_DEBUG=2 so that you can see its traffic, you should see it clearing the MeetingIsSet property when you dismiss an alarm, and you should no longer get notified of the same alarm when you start Outlook. -- 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
[Evolution-hackers] Vikash Ruhil wants to stay in touch on LinkedIn
LinkedIn I'd like to add you to my professional network on LinkedIn. - Vikash Ruhil Vikash Ruhil IT Security consaltant at Xiarch Solutions Pvt. Ltd. New Delhi Area, India Confirm that you know Vikash Ruhil https://www.linkedin.com/e/o7s0uh-gks4vloz-6h/isd/2426264280/3uGOS_fb/ -- (c) 2011, LinkedIn Corporation___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
