On Wed, 2004-09-15 at 15:22, YuLei wrote: > å2004å09æ13æç19:50ïArmin Baueråéï > > On Sun, 2004-09-12 at 15:01, YuLei wrote: > > > > On Sat, 2004-09-11 at 22:25, YuLei wrote: > > > > > Thanks for your reply. > > > > > > > > > > > Hi. thanks for your patches! > > > > > > > > > > > > On Sat, 2004-09-11 at 18:44, YuLei wrote: > > > > > > > After some weeks hacking, multisync is now usable for me. > > > > > > > I am using T68, Evolution and Palm on Debian Sarge with chinese GBK > > > > > > > environment, and I hope multisync will be my final solution for sync PIM > > > > > > > data with different devices. > > > > > > > > > > > > > > Here are my patches: > > > > > > > 02-palm_category.patch > > > > > > > -- see > > > > > > > http://sourceforge.net/mailarchive/forum.php?thread_id=5437490&forum_id=12899 > > > > > > > > > > > > > > > > > > > ok to commit. > > > > > > > > > > > > > 03-utf8.patch > > > > > > > -- see > > > > > > > http://sourceforge.net/mailarchive/forum.php?thread_id=5092577&forum_id=31160 > > > > > > > > > > > > > > > > > > > this patch converts a vcards encoding to UTF-8 if it is something > > > > > > different, correct? > > > > > yes. > > > > > > > > > > > Why are you working on the vcards directly? Wouldnt it be much better to > > > > > > use the libversit? > > > > > records from my T68 is UTF-7 encoding, and some value has the property > > > > > 'CHARSET=UTF7', but in function 'sync_vtype_convert', this property has > > > > > not been used, and the output value of vcard also lost this property, so > > > > > Evolution will get the wrong value because no charset specified > > > > > > > > > > Sorry, I know nothing about libversit :( , maybe that is the better way > > > > > > > > > > > > > it is a library used to manipulate vcards. you can find it under > > > > src/libversit > > > Ok, I will check it > > > > > > > > > BTW: the g_strescape madness in my palm plugin was already fixed in CVS > > > > > > :) > > > > > yes, this is not included in my patch :) > > > > > > > > > > > > > > > > > > > > > > > > 04-evo_utf8_char_edge.patch > > > > > > > -- line of records got from evoluion will be wrapped if too long, but > > > > > > > evolution does care nothing about the edge of characters which has > > > > > > > multi-bytes encoding, such as UTF8, if wrap occured in the middle of one > > > > > > > such character, multisync will crash because invalid UTF8 character, so > > > > > > > I add this patch to join all wrapped lines before do any processing. > > > > > > > > > > > > And i dont really understand what you mean with "if wrap occured in the > > > > > > middle of one such character" > > > > > because UTF8 is multi-byte encoding, this means an atom character of one > > > > > language (such as chinese) may has 2 or 3 bytes, if you wrap a line at > > > > > the fixed width, you cannot guarantee the wrap point is not inside in an > > > > > such character, maybe will break a multi-byte character into two lines, > > > > > multisync can not handle this, and will crash, so the easy way to > > > > > prevent this is to first join all the wrapped lines > > > > > > > > > > > > > ahh ok i get it. but your patch will break legitimate "\n" by removing > > > > them. Therefore it cannot be commited like this. The question is: Which > > > > program enters these linebreaks in multibyte chars? > > > Evolution does it, if a line like: > > > > > > DESCRIPTION:This year's LinuxTag will take place at June 23rd > > > > > > evolution will wrap this line to: > > > > > > DESCRIPTION:This year's LinuxTag will take place at June > > > 23rd > > > > > > it does wrap at the edge of a word 'June', because a space character > > > delimit the words 'June' and '23th', > > > this is right. But in UTF8 or other encoding with chinese language, no > > > such delimiter between words and characters, > > > like this: > > > > > > 0xe7 0xbc 0x96 0xe7 0xa0 0x81 > > > > > > the above is two chinese characters as one word in UTF8 encoding > > > (translate to english means 'encoding'), > > > wrap such a line must be done between third and fourth byte, but > > > evolution does wrap at the fixed width because no delimiter was found, > > > so does the problem. > > > The formal way to resolv this is to detect the word boundery, but this > > > is very hard and should based on dictionary, there for, search the edge > > > of one chinese character is easier by using 'g_utf8_validate', but the > > > easiest way is to join them all. > > > For the problem of eating legitimate "\n", all the special characters of > > > value in vcard has already been escapped, so the embedded "\n" will be > > > literal '\' and 'n' and should not cause problem. > > > > > > > then it should be ok to commit (with the memmove changes of course) > > > > > > > > > > > > > > btw: strcpy(p, p+2) ? > > > > > > > > > > > > man strcpy > > > > > > <snip> > > > > > > The strings may not overlap, and the destination string dest must be > > > > > > large enough to receive the copy. > > > > > > <snap> > > > > > this code is to remove the trail '\n' and the first space character of > > > > > next line, I don't know the problem of this code ? > > > > > > > > > > > > > well... strcpy(p, p + 2) would copy overlapping strings. It might work, > > > > it might not. Who knows. > > > yes, you are right, thanks! and memmove should be used instead of > > > strcpy: > > > memmove (p, p + 2, strlen (p + 2) + 1); > > > > > > > > > > > > > > > > > > > > > > > 05-evo_lost_records.patch > > > > > > > -- see > > > > > > > http://sourceforge.net/mailarchive/forum.php?thread_id=5319816&forum_id=31160 > > > > > > > > > > > > > > > > > > > cant comment on this one. i dont know enough about the inner workings of > > > > > > the evo plugin > > > > > this problem is exist, I cost many time to debug, if the record number > > > > > is large (> 400), after sync, you can see the debug message "We found xx > > > > > unexpected changes" > > > > > > > > > > > > > > > > > > 06-evo_work_fax_entry.patch > > > > > > > -- sync T68 to Evolution, phone with label 'Work' on T68 will save to > > > > > > > 'Work' entry on Evolution, that's ok, but this entry will never sync to > > > > > > > Palm, instead, multisync sync 'Business' entry on Evolution to Palm as > > > > > > > 'Work', this patch convert all 'Work' entry from T68 to 'Business' and > > > > > > > 'Fax' to 'Business Fax'. > > > > > > > > > > > > why are you fixing this on the evo side? you say that "TEL;WORK" will > > > > > > appear in evo as "Work", correct? > > > > > yes > > > > > > > > > > T68 Evolution Palm > > > > > ------------------------ > > > > > Work -- Work > > > > > Business -- Work > > > > > | | > > > > > +----- break ------+ > > > > > > > > > > > > > Hmmm... i dont have a "Work" label in Evolution. Anyways... can you show > > > > me a vcard that is added to the palm which the palm doesnt add > > > > correctly? > > > sorry, the label is 'Company' not 'Work', > > > a vcard get from T68 is like this: > > > Got 1 changes. > > > Change type: 1, object type: 2 > > > Comp: > > > BEGIN:VCARD > > > VERSION:2.1 > > > N:Test; > > > FN:Test > > > TEL;WORK:1234 > > > END:VCARD > > > > > > this card will sync to the entry with label 'Company' on Evolution, > > > then sync Evolution with Palm: > > > Process: 0 1 > > > Got 1 changes. > > > Change type: 2, object type: 2 > > > Comp: > > > BEGIN:VCARD > > > VERSION:2.1 > > > X-EVOLUTION-FILE-AS:Test > > > FN:Test > > > N:;Test > > > TEL;WORK:1234 > > > UID:pas-id-4144395100000001 > > > END:VCARD > > > > > > [remote] ERROR: Unknown TEL entry > > > Got 0 changes. > > > Get changes done. > > > Synchronization success! > > > > > > multisync reports an error message, but synchronization is success. > > > > > > However, because the address book of Evolution has four default phone entry: > > > 'Business', 'Home', 'Business fax' and 'Mobile', I want the work phone from T68 > > > to be the 'Business' phone on Evolution not 'Company', like palm plugin does > > > (palm_sync/src/vcard.c,line 778-780). > > > > > > > i guess that the t68 is synced with the ircm plugin, correct? Does this > > plugin generate the vcards itself or does it get them from the device it > > is connected to? > Yes, it's use IrMC plugin, and gets vcards from device directory
Ok. then your patch is correct. but i dont know if we should commit it to cvs since mapping TEL;WORK to "Company" is the default evo behaviour and other people might complain if this is changed... Comments anyone? > > > > > > Additionaly, add an new feature like 'field mapping' to multisync may be > > > a good solution, I think > > > > That idea is been around some time ago... if you can come up with a > > clean and easy to use interface it could be implemented > Maybe I will implement it if I have time :) > > > > > > > > > > > > > > > > > > If this isnt synced to "work" on the palm properly it should be fixed on > > > > > > the palm plugin. > > > > > I think this is only a quick fix, or fix this at IrMC plugin is better > > > > > > > > > > > > > > > > > > > > > > > > > 07-irmc_cant_remove_rec.patch > > > > > > > -- a deleted record on T68 will not be deleted after synchronize and > > > > > > > just become an empty record on Evolution > > > > > > > > > > > > looks good from here. but maybe change ret < 0 to ret != 0. Dont know if > > > > > > there are positive error codes. Comments anyone? > > > > > maybe yes, I don't know > > > > > > > > > > > > > > > > > > > > > > > > > 08-multi_filter.patch > > > > > > > -- filter now support multiple items with comma separated, such as > > > > > > > category list > > > > > > > > > > > > looks good. great idea btw :) > > > > > thanks :) , I have too many address records, and can not put all of them > > > > > to my T68, so I use filter to sync some of them to T68 based on category > > > > > > > > > > > > > > > > > > > > > > > > > 09-evo_preserve_categories.patch > > > > > > > -- if some records was modified on T68, after sync with Evolution, all > > > > > > > categories info on Evolution will be lost > > > > > > > -- same problem with 'Note' entry on Evolution and Palm, because there > > > > > > > is no such entry on T68, so, if a record was modified on T68 and then > > > > > > > sync back, this entry will be lost. I will try to fix this if I have > > > > > > > time. > > > > > > > > > > > > could you please elaborate a bit more on this problem (the first part). > > > > > > So a contact with categories is synced to the T68, then modified. If it > > > > > > is synced again the category information in evo will be lost, correct? > > > > > > does the t68 support categories? > > > > > this patch is a bit complex, for my poor English, maybe my code is the > > > > > better way to explain, sorry :( > > > > > T68 does not support categories, but it has a fixed category named > > > > > 'APPOINT' for tasks and events, and no category for address book > > > > > > > > See the next discussion point. > > > > > > > > > > > > > > > > > > > > > To the second part: This cannot be fixed in this version of multisync. > > > > > > The current syncengine is no "smart" engine that is able to merge the > > > > > > information of vcards. So if a device cannot support certain atributes > > > > > > of the vcard, is modified and then synced back, then unsupported > > > > > > information will be lost. There is no way to prevent this. Every attempt > > > > > > will probably be a crude hack that will work for you but might break > > > > > > things for others. > > > > > > > > > > > > The next version of multisync will hopefully be able to deal with this. > > > > > I think the syncengine should has its own database to save all the data > > > > > of individual devices separately, and can merge the changes of two > > > > > devices when sync between them > > > > > > > > > > > > > I dont think this can be done with the current syncengine (at least not > > > > too easy) > > > yes, I agree. > > > > > > > > > > > > > > > > > > > > > > > 10-evo_default_category.patch > > > > > > > -- add default category 'Unfiled' to any changed records if no category > > > > > > > was specified, because I have no idea to find out the records which has > > > > > > > no category on Evolution's addressbook > > > > > > > > > > > > why are you adding this Category? And why exactly "unfiled"? > > > > > > > > > > > because the records of address book on T68 has no categories, and > > > > > Evolution has bug of searching records which has no categories, so if I > > > > > add a new address record on T68 and then sync to Evolution, it is hard > > > > > to find out > > > > > > > > What exactly is this bug with Evolution searching of contacts without > > > > categories? > > > yes > > > > I dont think we should possibly break synchronization for other users to > > > > fix a bug in evolution. > > > but I have no other good idea, maybe this will be an option for bug workarounds > > > or be my private modification for my convenient > > > > thats of course always an option :) > > but you would have to make modifications to the gui of the evo plugin > > since it doesnt have a "Options" tab (you could add this to the main > > page of course) > Or I will waitting for the next version of Evolution that can find out > such records ;) > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > > > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > > > > who ports your project to Linux PPC the best. Sponsored by IBM. > > > > > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > > > > > _______________________________________________ > > > > > Multisync-users mailing list > > > > > [EMAIL PROTECTED] > > > > > https://lists.sourceforge.net/lists/listinfo/multisync-users > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > > who ports your project to Linux PPC the best. Sponsored by IBM. > > > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > > > _______________________________________________ > > > Multisync-users mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/multisync-users > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: thawte's Crypto Challenge Vl > Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam > Camcorder. More prizes in the weekly Lunch Hour Challenge. > Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m > _______________________________________________ > Multisync-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/multisync-users ------------------------------------------------------- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m _______________________________________________ Multisync-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/multisync-users
