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.