On Thu, 2010-04-29 at 08:14 +0100, Tino Keitel wrote:
> On Thu, Apr 29, 2010 at 08:48:17 +0200, Tino Keitel wrote:
>
> [...]
>
> > But I also see that the alarmTimeToUTC is now mentioned in the log, so
> > the rule seems to be applied.
>
> Oh, it isn't. I started the server in strace, and it never seems to
> look into syncevolution-xml/remoterules/client, only .../server. So I
> copied the rule to syncevolution-xml/remoterules/server, and alarms now
> appear on the phone. Thanks a lot.
You are right, I suggested the wrong directory. "client" is used *on* a
client, not *for* clients. I have added the rules file to SyncEvolution.
This leads to two issues:
* Should all Nokia phones get this treatment if there is no more
specific rule? There are plenty of different models which are
likely to behave similar. We shouldn't be forced to add a rule
for every single one. Technically it is possible, the point is
whether we should extrapolate from one example to all... perhaps
not quite yet. http://bugs.meego.com/show_bug.cgi?id=1657
* Improve syncevo-phone-config to cover rules.
http://bugs.meego.com/show_bug.cgi?id=1658
On Thu, 2010-04-29 at 08:41 +0100, Tino Keitel wrote:
> Hum, there is still something wrong.
>
> If I set an alarm with 5 or 15 minutes or some other value which the
> phone can set in its GUI, then it works as expected. The alarm is
> shown, and if I edit the appointment on the phone, it works too.
>
> If I set another alarm, like 6 minutes, it is shown as expected ("5
> minutes before"), but additionally there is a different clock icon
> shown with the absolute alarm time. The alarm is triggered at the
> correct time. But if I edit the appointment, the alarm gets lost.
>
> However, I just tried the same with mobical.net, and experienced the
> same. I looks like the phone is broken in the way it handles alarm
> times with other than predefined values.
So this is nothing that can be fixed by SyncEvolution, right?
--
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
