----- Original Message -----
From: Matt Davey
Time: 18-11-08 11:30
Hi Tom,
On Mon, 2008-11-17 at 22:42 +0100, Tom Billiet wrote:
Hi Matt,
It took me a long time to get it tested. First because of a lack of
time, and secondly because I took my z22 for a ride in the washing
machine. It takes an awful long time to get the water out of the
touchscreen, but magically everything seems to be working, and it
still had all my data. Actually I must say I was quite surprised it
survived it :-)
That is good news indeed. Nice surprise!
Anyway, I got now to testing it.
I applied your patch against the svn version of evolution and e-d-s
from today, and it compiles fine (on archlinux). It also tried 1. and
2. you mentioned, and it seems to be working ok. I'm not sure how to
test the other points.
So the basic testing I've done looks fine. It's good to see some bugs
to get solved.
Many thanks for the testing. Did you sync with a previously synced
device+addressbook? I suspect there's a possibility that all (or many)
addresses could get duplicated on first syncing with the new logic,
because the desktop will now "package" an address in a slightly
different way (basically, I've aimed to avoid re-ordering fields on the
pilot as much as possible).
As a matter of fact, I did the sync with all my current data. And as
far as I can see, I don't spot any duplicates. The record I made for
testing was a new one however.
Also, I've configured the address conduit only to copy from my pda to
evolution. As otherwise the new os5 fields will be overwritten as soon
as I make a change in evolution. So I only make changes in my pda.
I'm having a bit of a job persuading the Evolution maintainers to commit
the e-d-s part of the patch (see bug 556061:
http://bugzilla.gnome.org/show_bug.cgi?id=556061 ) as my fix for the
reordering problems could change behaviour that is being relied upon by
other workarounds. Unfortunately, without the changes on the e-d-s side
I can't fix the pilot bugs. Hopefully it's just a case of getting
consensus that a) there are bad bugs b) they need to be solved at the
e-d-s layer and not worked around elsewhere and c) if we miss any cases
elsewhere we can address them as they are identified.
Part of the problem is the lack (to my knowledge) of any regression test
suite for evolution. It's a complex beast, and it's all too easy to
introduce bugs when trying to fix other ones.
I hope you get your fixes submitted.
Thanks again, Tom,
Matt
You're welcome,
Tom
Btw: my email address has changed, so do not try to contact me anymore
on my old address, I won't receive your mails.
Kind regards,
Tom
----- Original Message -----
From: Matt Davey
Time: 05-10-08 23:52
Dear code monkeys,
I'm attaching two patches, one for evolution-data-server and one for
evolution. Together, they seem to fix some pretty bad bugs in the
address conduit. I would appreciate it if anyone out there was willing
to test these patches (Tom, Nathan?).
The diffs are against Evolution branch 2.24 as the trunk would require
me to upgrade my glib and a bunch of other stuff, or build from
gargnome, neither of which I fancy just now. 2.24 was only branched a
couple of weeks ago, so it is pretty up to date.
I haven't yet attempted any support for the new Contact fields. This
patch is just to fix existing addressbook bugs. The sync logic,
particularly for the phone and email fields has changed considerably.
Bugs I've tried to fix:
1. The 'first-name / family-name' split on the palm was not
respected when writing to the desktop. It went via 'full_name'.
See bug #269342 for some more info. (aside: IMO Evo full_name
munging is far too fragile to be worth using and I wish they'd
get rid of it. It's never going to reliably separate first/last
names when challenged by, say "Mary Anne Bloggs" and "John Mc
Neill")
2. If you erased a phone field on the Palm, it wouldn't be erased
on the desktop.
3. The 'OTHER' phone fields were broken in various ways. This is
actually already fixed on the 2.24 branch (and trunk) since
revision 9380 (see bug #547223)
4. There were many ways for phone fields to be re-ordered. I've
tried to avoid this wherever possible.
5. Evolution was careless about ordering of multiple email/phone
entries in the vcard. For example, if you imported a 'vcard'
with 3 emails, and then saved it immediately, you would find the
3 entries would be reversed. This sort of thing could upset the
palm.
6. If you had an entry on both desktop and palm, and say you had
three phone numbers labelled 'home' on the palm. Then that
entry could be deleted if you changed the desktop record and
synced again.
I will probably have to break down the patch into a few components
before submitting to the Evolution maintainers, but I'd appreciate it if
anyone was able to do some testing or take a look over the changes in
the meantime.
Thanks,
Matt
Matt Davey I like to browse in occult bookshops if for no other reason than
mcdavey mrao cam ac uk to refresh my commitment to science. -- Heinz Pagels
_______________________________________________
gnome-pilot-list mailing list
gnome-pilot-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-pilot-list
Matt Davey To err is human, to moo bovine.
mcdavey mrao cam ac uk
_______________________________________________
gnome-pilot-list mailing list
gnome-pilot-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-pilot-list
|
