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,
does someone knows what those files are and where it is coming from. How this can be changed/configured?
ls -1 .trinity/share/apps/tdeabc/ std.vcf std.vcf__0 std.vcf__1 std.vcf__10 std.vcf__11 std.vcf__12 std.vcf__13 std.vcf__14 std.vcf__2 std.vcf__3 std.vcf__4 std.vcf__5 std.vcf__6 std.vcf__7 std.vcf__8 std.vcf__9
I mean std.vcf__0 etc
thanks in advance
regards
On 04/06/2016 04:55 AM, deloptes wrote:
Hi,
does someone knows what those files are and where it is coming from. How this can be changed/configured?
ls -1 .trinity/share/apps/tdeabc/ std.vcf std.vcf__0 std.vcf__1 std.vcf__10 std.vcf__11 std.vcf__12 std.vcf__13 std.vcf__14 std.vcf__2 std.vcf__3 std.vcf__4 std.vcf__5 std.vcf__6 std.vcf__7 std.vcf__8 std.vcf__9
I mean std.vcf__0 etc
thanks in advance
regards
Hi Deloptes, sorry for the late reply. I also have similar files on my system. They are vcards, they seems to be created by KOrganizer when the main window is displayed (you can try deleting them and opening KOrganizer window a few times to see them come back). Not sure why they are created, would have to check in the code. Perhaps it is a bug, what do you think? Feel free to open a bug report if you want.
Cheers Michele
Michele Calgaro wrote:
regards
Hi Deloptes, sorry for the late reply. I also have similar files on my system. They are vcards, they seems to be created by KOrganizer when the main window is displayed (you can try deleting them and opening KOrganizer window a few times to see them come back). Not sure why they are created, would have to check in the code. Perhaps it is a bug, what do you think? Feel free to open a bug report if you want.
Cheers Michele
Thanks Michele, I was hoping someone knows the code better than me and would eventually know where is the responsible part. I have this since ages from the kde3 time. I think it is a cached data. The problem is not visible when you use the AddressBook (I think it shows always the latest version/revision) but is becoming an issue when I sync up (delete) as the deleted reappear (looks like from cache).
I now delete those manually before I sync and the symptoms are gone.
I agree with you one need to look in the code and understand what is the use of those files and what is missing there. It looks like cache flush or something alike.
The moral of this whole journey is that not only OpenSync did damage in the past, but I am now more experienced than 10y ago and I dare chasing those.
regards
deloptes wrote:
Michele Calgaro wrote:
regards
Hi Deloptes, sorry for the late reply. I also have similar files on my system. They are vcards, they seems to be created by KOrganizer when the main window is displayed (you can try deleting them and opening KOrganizer window a few times to see them come back). Not sure why they are created, would have to check in the code. Perhaps it is a bug, what do you think? Feel free to open a bug report if you want.
Cheers Michele
I just now found some time to snoop around for the source of this. The answer is in tdeabc/plugins/file/resourcefile.cpp
bool ResourceFile::doOpen() { TQFile file( mFileName ); [...] for (int i=0; i!=20; i++) { TQFile backup( mFileName + "__" + TQString::number(i) ); [...] }
void ResourceFile::doClose() { }
interesting why it leaves he files and more interesting why it caches the data from those files.
The code however is not that intelligent if you look into it (i!=20), so perhaps we can improve a bit.
(to be continued)
regards
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.
Cheers Michele
-
deloptes -
Michele Calgaro