Alarm user on alarm

[teto]

I had looked for a program like khal one year ago without success but I am very glad to have found it. My question is not directly related but might become. I am looking for a daemon able to read my calendar and warn me via popups when an event is closing in. Thunderbird does warn me but only when it's open. So I was wondering if anyone knew of such a tool and if not, would it make sense to divide khal into a daemon and a client application (as urxvt or powerline).

[untitaker]

Khal could use atd instead of launching its own daemon.

[untitaker]

Also I think @michaeladler wrote something like this for his own use?

[geier]

Without thinking too much about this, I'm not a fan of writing our own
daemon here. Using either at or cron and any notification
program comes to my mind.

Quoting Markus Unterwaditzer (2015-01-29 18:05:40)

Also I think @michaeladler wrote something like this for his own use?

---

Reply to this email directly or view it on GitHub:
#148 (comment)

[teto]

Somehow the workflow would be, write a cronjob that polls every X minutes from khal events within next X minutes events and pass those events to at ?
This should be enough if X is low. Otherwise if the calendar changes (event removed, or close event added) during the next X minutes it may become complex to handle.

[michaeladler]

@untitaker: Nope, I pretty much wrote the opposite: a tool that removes annoying alerts from ics-files :)

[teto]

@michaeladler I would like to be annoyed by such a tool, any name in mind ?

[geier]

I'm happy to support any such endeavor with any custom functions needed, but won't get to implement the tool itself for quite some time.

[geier]

@mbaldessari 's suggestion:

It would be extremely cool to have something (just thinking aloud here) like:
khal alarms --script foo --delta 60min which will call foo for every event that will take place
in the next 60 minutes (passing the subject of the event + time as args). That way it could
be put in a cron job pretty easily.

[untitaker]

I think that's problematic. If the command you posted were to be executed every hour, it could miss events that are happening within 60 mins and were synced recently. If the user tries to mitigate this by calling that command more often, the given script would be executed multiple times for one event.

I think a better approach is a hook in the config file that is called whenever khal pleases to do so. But in that case, the next version of vdirsyncer will include such a hook, it will invoke a script for each new or updated ics file, thanks to @michaeladler.

[teto]

Commit susmentioned is this one I guess: pimutils/vdirsyncer@2084534 . Cool stuff. The easiest way would to go for the hook would be to remove all the previously registered cronjobs and recreate them.

[untitaker]

@teto In that case you might as well not rely on any hooks, and traverse the directories yourself.

I suppose we'll need another hook for deleting items?

[teto]

I was not sure if the hook would react on a delete but it is needed I guess. You say " traverse the directories yourself." but how often ? you can do it every every X min or when the hook triggers. This way you skip useless updates. Tracking changes on a 1 to 1 mapping looks harder to me then just reset cronjobs. I dunno if there is exists a ID/hash per event ?