在2004年09月16日的02:51，Armin Bauer写道： > 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? Hmmm...I think the 'field mapping' is the best solution. Another way, we can do a test of existence of "TEL;WORK;VOICE" in which get from other devices, if no, move "TEL;WORK" to "TEL;WORK;VOICE", otherwise do nothing
> > > > > > > > > > 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: 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. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Multisync-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/multisync-users
