On Mon, 2006-10-30 at 18:25 +0100, Patrick Ohly wrote: > I should have mentioned that I am subscribed now, so we could continue > the discussion on the list. Feel free to forward your email and my > reply.
Done, so those finding the thread via Google can see its conclusion. > On Mo, 2006-10-30 at 10:05 -0600, Michael Ekstrand wrote: > > On Sun, 2006-10-29 at 22:16 +0100, Patrick Ohly wrote: > > If I remember correctly, that was the most significant issue. I think > > there's probably some things that Evolution could be doing better; I > > think that it should assume some reasonable defaults to allow > > information to at least be visible when it can't find its custom > > properties. But the destruction of custom properties rendered it so > > that I could not view the phone numbers for a contact in Evolution until > > I edited and re-saved the contact. > > I agree, Evolution could have been smarter, but I believe I have worked > around this in 0.4. From the "known problems" list: > > Evolution GUI > When importing or updating a contact from the server, some > telephone numbers might only be displayed in the contact summary > after editing the contact once. Evolution 2.0.4 till 2.6.3, > ContactSync::testMerge test. Starting with SyncEvolution 0.4 > this is solved by modifying the contact in the same way as the > internal editor does. If it still fails, the server might send > phone numbers without setting their type correctly. Perhaps I should go in and make a formal bug report about this, if I can document sufficiently. > > I did play with the SyncEvolution source in an attempt to make it set up > > some default display properties when it saved a contact; this wound up > > not working. > > I followed the same approach; I guess we simply tried slightly different > things. Would you mind trying 0.4 again? I'll give it a shot. It looks like my attempts were against the 0.4pre2 sources. > > I think some of the rest of the issue was connected with the inability > > for SyncML to neatly pick up on deleted fields - I wound up with > > duplicated phone numbers when I was trying to do some initial testing. > > This might be better now that ScheduleWorld has settings for devices > that tell the server how many phone numbers the device supports: if you > set it to maximum for both your clients, then the server should be able > to distinguish between "device has discarded phone number" and "phone > number was deleted". There are some usability problems (like having to > sync once before being able to set the value and having to do it > manually in the first place, missing documentation, ...) but it might be > worth another try. OK. > > And I'd seen the SyncEvolution/ScheduleWorld combo as a hack to > > accomplish what I wanted - ideally, I wouldn't need something like > > ScheduleWorld to keep these two computers in sync. > > Agreed, as soon as data conversion is involved there will be drawbacks. > In some case it simply cannot be avoided, though. Yeah. The Conduit project is looking quite promising in this regard though - hopefully it will develop into a useful solution soon. - Michael _______________________________________________ Evolution-list mailing list Evolution-list@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-list
