Re: [trinity-devel] TDEPIM with SyncEvolution

Hi all, I now have one version that I would consider working and of preproduction state. Next steps Is someone willing to test it, or how would you proceed in this case? I do not have cal/carddav accounts or any of the other supported peers. I have only two phones I could test with - Nokia 5530 and Nokia N9. It would be interesting to test with other phones, devices, systems etc. - at least the contacts and the calendar ( which I believe work fine now). Contacts and Calendar I tested address book (contacts) and calendar (events) extensively on both phones. Todos and Memos (journal) The 5530 has some strange calendar type, so todo and memo worked only from phone to TDE, but not v.v. for obvious reason. I am waiting now for some hints on how to configure (perhaps virtual calendar or special settings). On the N9 I did not test those extensively. I tested briefly todos and it works fine. Memos in N9 are TDE/Knotes (see below). Notes I also did not implement the classical KDE/TDE notes - but I will soon do so as this will be helpful for the N9 (and perhaps other phones/systems/peers too). I have the basic structure and functions, but this goes into a separate plugin and was not a prio. Build As SyncEvolution is using the automake system, the code is integrated into it. (Not sure if this is of any interest) Packaging SyncEvolution is provided by debian main line. Should the code be pushed there or we could provide a deb package with the tdepim part from within trinity? I am not sure if the debian main line will work with it. I had to explicitly disable some configure options to have it working. What does one do in such a case? Provide the full package? I would need some help here and brainstorming as well. Code availability Where would you upload the code for testing in this case? What is the "standard" procedure. I dislike google but have account @sourceforge Is the latter good to go? Optimization There were some good advises from Fat-Zer regarding string encoding, but I couldn't follow (as my time window is closing now), so I still convert the TQString into std::string and then assign the content. (One could save some memory here and there). valgrind does not complain about the code - it looks clean. Fun I had some issue yesterday on the test env (2G mem) where it crashed, because of memory exhausted. It turned out that opening the log file in konqueror consumed 1,7G :D ... I was thinking for a moment - come one, you were just syncing fine until last start of the virutal machine ... WTF happened, but it was the konqueror and the log file :D I also didn't follow up with the parseVCard - I'm not sure if it needs to be handled as a bug - it seems to be left over from the babylonian times, but someone has to retest and work it out properly and I do not think that I could spend the time now and take the responsibility. thanks in advance for your patience and support regards