On Wed, 2010-05-12 at 14:59 +0100, Chris G wrote:
On Wed, May 12, 2010 at 01:33:24PM +0200, Patrick Ohly wrote:
> On Wed, 2010-05-12 at 10:52 +0100, Chris G wrote:
> > On Wed, May 12, 2010 at 08:42:37AM +0200, Patrick Ohly wrote:
> > > On Tue, 2010-05-11 at 22:05 +0100, Chris G wrote:
> > > > While I'm about it running syncevo-phone-config.py was rather
painful
> > > > because I had to accept hundreds of bluetooth connections to my
phone
> > > > while syncevo-phone-config.py was running.
> > >
> > > I know exactly what you mean. My Sony Ericsson K750i had a joystick that
> > > was so worn out that I could no longer navigate to the "always
accept"
> > > option. Eventually I managed to reach that point by brute force.
> > >
> > > Regarding running syncevo-phone-config.py: this is definitely not the
> > > recommended way to create a config. I bet it arrived at the same
> > > configuration that we already ship as template for S40 and S60 Nokia
> > > phones, so you could have chosen one of those instead.
> > >
> > It does seem to have got to something pretty similar, in fact I don't
> > think I see any difference between S40, S60 and my self-created E71.
>
> There's one difference: "calendar" and "todo" are active,
using the same
> URI, whereas "calendar+todo" is inactive. The right configuration would
> have only "calandar+todo" as active.
>
> Please fix this as follows:
> syncevolution --configure --source-property sync=none \
> <config> calendar todo
> syncevolution --configure --source-property sync=two-way \
> <config> calendar+todo
>
> Then try again.
>
It doesn't appear to change anything much
One more try - remove the URI from calendar and todo:
syncevolution --configure --source-property uri= \
<config> calendar todo
I suspect that what happens is that the phone alerts us for the
"Calendar" uri, and then SyncEvolution doesn't know exactly whether that
is "calendar", "todo", or "calendar+todo". It ends up
picking "todo"
when it should have used "calendar+todo".
--
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.