View Single Post
Posts: 479 | Thanked: 641 times | Joined on Dec 2007 @ Switzerland
#90
Originally Posted by Palleman View Post
No recurring events though (which is not only bad, since I won't have a couple of hundred birthdays duplicated).
Yes, recurring events are not managed yet. In fact I just discovered that the recurring events support in Fremantle Calendar is very poor (it won't accept "exceptions")....

Or, is there a way to change which local calendar is the default when adding new events?
Not that I know, but this would be very useful!

Is there a way to fiddle with the .db to change the binding from the new calendar to the default N900 calendar?
There's probably a way to coerce Erminig and the local calendar to do that, but I don't think that I'm going to investigate this further, since it doesn't appear to be a common use-case, Next version will allow the user to sync to an already existing calendar, without forcing the creation of a new one.

It is slow and it's eating resources, but I guess that's what you get for running stuff that's not even in a .deb yet, and in addition doing it with a massive data source and output straight to the screen...
How massive the data source (how many events)? And from where? (Google or local calendar?).

Concerning the slowness: normally it's only the first sync that may be slow, since it has to fetch quite a lot of information from Google, all subsequent syncs should be faster.

Concerning eating resources: do you mean memory resources or CPU resources?
Memory usage at first sync increases in O(n), with n being the number of events, and more generally it's also O(n) in the subsequent syncs, but here n is the number of modified/new/deleted events (and not the total number of events)

And yes, output of the debug data to the screen will not help. All that output will be removed in the next version, and only a few lines will be logged in an ad-hoc log window.