[Evolution-hackers] Last minute "vfolder-prep" branch merge
Srini asked me to merge his "vfolder-prep" branch in time for Evolution 3.4, and I wasn't around much last week so this is kind of last minute. This branch just stages some of the vfolder and filtering code to be moved to Evolution-Data-Server after 3.4. The GTK+ parts of some of those classes have been split into separate "ui" subclasses, similar to how EMailUISession was forked from EMailSession. The branch also introduces yet another little utility library named libevolution-utils. This is just a temporary library. The plan is to move its APIs into libedataserver[ui], but it's a little late to do that for 3.4. The library contains most of the EAlert APIs and some other odds and ends from libeutil, so that created a bit of a splash across the source code. I know it's bad juju to do this right before a release, but the source code is only being reorganized, Srini assures me it works well, my own testing seems to confirm that, and I'm doing my due diligence to make sure everything builds smoothly for Monday's release. Matthew Barnes ___ 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] PHOTO uri + escaping
Hello! I am seeing an issue where the Synthesis engine doesn't parse a vCard with PHOTO;VALUE=uri the same way as libebook's e_contact_inline_local_photo() does. The vCard has: PHOTO;VALUE=uri:file:///home/nightly/.local/share/evolution/addressbook/130 3826927.6946.21@mob-sync2/photos/pas_id_4F511ADB000F_photo-file0.image %252FGIF The actual file name is: /home/nightly/.local/share/evolution/addressbook/1303826927.6946.21@mob-sync2/photos/pas_id_4F521E7A000F_photo-file0.image%2FGIF Note that %2FGIF was encoded as %252FGIF in the vCard. The Synthesis engine does no decoding of the %25 before trying to read the file. I think this is a bug, and I take full credit, eh, blame for it as I added that too simplistic URI handling code ;-) However, why does the file name end in %2FGIF in the first place? It would be much more readable to just use .GIF. That notwithstanding, of course I intend to fix the bug in the Synthesis engine. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ 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] libebook master: obsolete vCard used despite updated properties
Hello!
I tested SyncEvolution against current EDS master and found a problem:
setting a UID before committing an updated contact has no effect.
The sequence of events is this:
1. e_contact_new_from_vcard() where the vCard contains no UID.
2. e_contact_set(E_CONTACT_UID, ) -> g_object_set()
3. e_book_commit_contact() -> e_vcard_to_string() -> D-Bus
In step 3, e_vcard_to_string() returns the cached evc->priv->vcard
without the UID although it has a UID in its attributes
(evc->priv->attributes).
I think the culprit is this commit here:
commit cca25e98a71d8c06f9ce1b53658ec4675f2dd5c2
Author: Bartosz Szatkowski
Date: Tue Oct 18 12:29:07 2011 +0200
Bug #656603 - Add support for generating vCard 2.1 in libebook
[...]
@@ -1016,17 +1246,16 @@ e_vcard_to_string (EVCard *evc,
{
g_return_val_if_fail (E_IS_VCARD (evc), NULL);
- /* If the vcard is not parsed yet, and if we don't have a UID in
priv->attributes
- return priv->vcard directly */
- /* XXX: The format is ignored but it does not really matter
-* since only 3.0 is supported at the moment */
- if (evc->priv->vcard != NULL && evc->priv->attributes == NULL)
- return g_strdup (evc->priv->vcard);
-
switch (format) {
case EVC_FORMAT_VCARD_21:
+ if (evc->priv->vcard && strstr_nocase (evc->priv->vcard, CRLF
"VERSION:2.1" CRLF))
+ return g_strdup (evc->priv->vcard);
+
return e_vcard_to_string_vcard_21 (evc);
case EVC_FORMAT_VCARD_30:
+ if (evc->priv->vcard && strstr_nocase (evc->priv->vcard, CRLF
"VERSION:3.0" CRLF))
+ return g_strdup (evc->priv->vcard);
+
return e_vcard_to_string_vcard_30 (evc);
default:
g_warning ("invalid format specifier passed to
e_vcard_to_string");
It removes the check for evc->priv->attributes. Adding that check back
fixes the problem.
Question: why does the removed comment only mention UID? Isn't any
contact modification detected by checking evc->priv->attributes?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
