Hello Klas! Sorry for the late reply - we were busy with 1.0 beta.
On Di, 2010-01-19 at 17:09 +0000, Klas Hultqvist wrote: > Yes "Configure" did seem to work. However, a recurrent event and maybe > something else seemed to disappear from the phone (without any > syncing), following a maemo upgrade. Ove recently mentioned a problem of the Maemo calendar implementation which was related to recurring events. Ove, do you have more details about this? I've no idea whether it is really related, though. > Trying to sync again I could make events from the phone turn up in > evolution, but not the other way around. Klas, is this with normal events or recurring ones? As with many such interoperability problems, we can check whether the data we send is sane and accepted by the peer. We would need a log file of a sync session where data is sent. You can send that to [email protected] and it will be treated as confidential. But in the end only the developer of the receiving software can explain problems in displaying the data once it was received. Congwu, can you try to reproduce this? > This made events from evolution turn up on the phone, but not all of > them. See above. > Also, I noticed that some events which I had deleted turned up in the > syncevolution log file. Seemed to me to be coming from the phone. That's normal. What happened is a "slow" sync, which merges data stored on both sides. > To summarise: > > 1. Some events don't make it to the phone. > 2. How could I empty caches and re-start from scratch, based only on > what is seen in the calendar applications? Do a "--sync refresh-from-server", where in this case SyncEvolution acts as the server with the data to be preserved being stored in Evolution. See also my recent post about preventing unwanted slow syncs - if enabled (and working for servers, which it doesn't yet), the slow sync would not have been done automatically. Does that sound useful? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
