Changes to calendar objects reg. alarms.

[Eskil Heyn Olsen <deity dbc dk>]

Oy...

My problem is as follows : calendar_new calls calendar_init_alarms, which
via. alarm.c(alarm_add) schedules alarms by calling setitimer(...).

Problem 1: The gnomcal conduit calls calendar_string_from_object (to
update gnomecal objects) which calls calendar_new. Thus the gpilotd has
effectvely now called setitimer, thereby causing SIGALRM's whenever
(todays?) gnomecal events have their alarm set.

Problem 2: corba-cal.c also calls calendar_string_from_object, thereby
causing multiple alarm.c(alarm_add) for the same events. This is related
to all gnomecal corba calls that use calendar_string_from_object (most of
them). This causes a event to generate multiple alarmboxes when the alarm
is called... bad.

Solution 1: let gpilotd register a handler for sigalrm.
Bad, since 1) it is a hack 2) it does not solve problem two,
which is a generic gnomecal problem 3) pilot-link uses sigalrm for serial
port watchdogging. Since problem two is not resolved, this is Not Good.

Solution 2: alter calendar_new to _not_ call init_alarms.
Since programs that want to alarms generated can call
calendar_init_alarms. This means the major calendar object in gnomecal can
call calendar_init_alarm itself (gnome-cal.c(gnome_calendar_new)).

Solution 3: make a convinient calendar_new_with_alarms call
As opposed to adding parameters to calendar_new, since it is actually only
gnome-cal that wants the alarms, everybody else would rather not have them
(due to problem two), thus a eg true/false parametere to calendar_new
would just be a hassle.

I lean towards solution 2, as it preserves the interface, and lets
the individual program choose to enable alarms.


/dev/eskil 
---