Message: previous - next
Month: April 2016

Re: [trinity-devel] TDEPIM with SyncEvolution

From: Michele Calgaro <michele.calgaro@...>
Date: Wed, 6 Apr 2016 20:13:58 +1000
On 04/04/2016 07:54 AM, deloptes wrote:
> 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
Hi Deloptes,
well done and thanks! The best way to report this, is to create a bug report in bugszilla, attach the code and mark the
bugs as enhancement and patch available status.
Sorry, I do not have phones for testing more. Perhaps some other users code do so after the code is integrated in the
main trunk.