New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alarm user on alarm #148

Open
teto opened this Issue Jan 29, 2015 · 31 comments

Comments

Projects
None yet
8 participants
@teto

teto commented Jan 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@untitaker

untitaker Jan 29, 2015

Member

Khal could use atd instead of launching its own daemon.

Member

untitaker commented Jan 29, 2015

Khal could use atd instead of launching its own daemon.

@untitaker

This comment has been minimized.

Show comment
Hide comment
@untitaker

untitaker Jan 29, 2015

Member

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

Member

untitaker commented Jan 29, 2015

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

@geier

This comment has been minimized.

Show comment
Hide comment
@geier

geier Jan 29, 2015

Member

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)

Member

geier commented Jan 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@teto

teto Jan 29, 2015

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.

teto commented Jan 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@michaeladler

michaeladler Feb 2, 2015

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

michaeladler commented Feb 2, 2015

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

@teto

This comment has been minimized.

Show comment
Hide comment
@teto

teto Feb 3, 2015

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

teto commented Feb 3, 2015

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

@geier

This comment has been minimized.

Show comment
Hide comment
@geier

geier Feb 3, 2015

Member

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.

Member

geier commented Feb 3, 2015

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 geier referenced this issue Feb 18, 2015

Closed

VALARM support #167

@geier

This comment has been minimized.

Show comment
Hide comment
@geier

geier Feb 18, 2015

Member

@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.

Member

geier commented Feb 18, 2015

@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.

@geier geier changed the title from Caldav daemon to launch popups before events to VALARM support Feb 18, 2015

@untitaker

This comment has been minimized.

Show comment
Hide comment
@untitaker

untitaker Feb 18, 2015

Member

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.

Member

untitaker commented Feb 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@teto

teto Feb 18, 2015

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.

teto commented Feb 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@untitaker

untitaker Feb 18, 2015

Member

@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?

Member

untitaker commented Feb 18, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@teto

teto Feb 19, 2015

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 ?

teto commented Feb 19, 2015

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 ?

@WhyNotHugo

This comment has been minimized.

Show comment
Hide comment
@WhyNotHugo

WhyNotHugo Apr 17, 2015

Member

at is probably better than cron for this since:

  • It provides an id for each job, making cancellation easier.
  • It looks simpler to schedule things for a determined date/time than via cron (from the top of my head: cron has no way of adding something for 2016-04-20 without it executing on 2015-04-20 as well)
  • It's really designed for this sort of one-off thing.

I'm not sure if khal should really be invoking at though. I'd much rather see a command for output similar to khal agenda but with the date included on every line. Something else can then pick that up and manage at event addition/tracking/deletion. Anything more is honestly rather out-of-scope for khal, IMHO.

This external job/notification tracker can either:

  • Run daemonized, detecting changes to the vdir (remember: they're atomic :D ). Guarantees that no events slip past between syncs.
  • As a vdirsyncer hook.

I've no real strong preference.

Member

WhyNotHugo commented Apr 17, 2015

at is probably better than cron for this since:

  • It provides an id for each job, making cancellation easier.
  • It looks simpler to schedule things for a determined date/time than via cron (from the top of my head: cron has no way of adding something for 2016-04-20 without it executing on 2015-04-20 as well)
  • It's really designed for this sort of one-off thing.

I'm not sure if khal should really be invoking at though. I'd much rather see a command for output similar to khal agenda but with the date included on every line. Something else can then pick that up and manage at event addition/tracking/deletion. Anything more is honestly rather out-of-scope for khal, IMHO.

This external job/notification tracker can either:

  • Run daemonized, detecting changes to the vdir (remember: they're atomic :D ). Guarantees that no events slip past between syncs.
  • As a vdirsyncer hook.

I've no real strong preference.

@mathstuf

This comment has been minimized.

Show comment
Hide comment
@mathstuf

mathstuf Aug 8, 2015

I think a daemon would be much easier to implement and get right. If you have a snooze on events, you'll need to react which means staying around until the user is "done" with the notification anyways, so you may as well just scan the ical files as needed and add timers to an internal event loop.

mathstuf commented Aug 8, 2015

I think a daemon would be much easier to implement and get right. If you have a snooze on events, you'll need to react which means staying around until the user is "done" with the notification anyways, so you may as well just scan the ical files as needed and add timers to an internal event loop.

@untitaker

This comment has been minimized.

Show comment
Hide comment
@untitaker

untitaker Aug 8, 2015

Member

It certainly gives us more flexibility for more sophisticated features.

Perhaps this daemon can also keep the database in memory, so the CLI has nicer
startup performance (similar to evolution-data-server's role). Not sure how
communication between daemon and client should look like.

On Fri, Aug 07, 2015 at 10:22:17PM -0700, Ben Boeckel wrote:

I think a daemon would be much easier to implement and get right. If you have a snooze on events, you'll need to react which means staying around until the user is "done" with the notification anyways, so you may as well just scan the ical files as needed and add timers to an internal event loop.


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

Member

untitaker commented Aug 8, 2015

It certainly gives us more flexibility for more sophisticated features.

Perhaps this daemon can also keep the database in memory, so the CLI has nicer
startup performance (similar to evolution-data-server's role). Not sure how
communication between daemon and client should look like.

On Fri, Aug 07, 2015 at 10:22:17PM -0700, Ben Boeckel wrote:

I think a daemon would be much easier to implement and get right. If you have a snooze on events, you'll need to react which means staying around until the user is "done" with the notification anyways, so you may as well just scan the ical files as needed and add timers to an internal event loop.


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

@teto

This comment has been minimized.

Show comment
Hide comment
@teto

teto Aug 20, 2015

As an alternative to the daemon solution gcalcli (https://github.com/insanum/gcalcli) proposes a remind command as a cronjob. Looks easier to implement ?
(I like the way they output the week schedule too).

teto commented Aug 20, 2015

As an alternative to the daemon solution gcalcli (https://github.com/insanum/gcalcli) proposes a remind command as a cronjob. Looks easier to implement ?
(I like the way they output the week schedule too).

@geier geier referenced this issue Aug 20, 2015

Closed

week view #251

@mathstuf

This comment has been minimized.

Show comment
Hide comment
@mathstuf

mathstuf Aug 21, 2015

IMO, you're going to want to run every 10 minutes or so anyways, so I see no reason not to just run as a daemon. No daemonization logic is needed either; use systemd --user, shell backgrounding, nohup, or other mechanisms to manage the process.

mathstuf commented Aug 21, 2015

IMO, you're going to want to run every 10 minutes or so anyways, so I see no reason not to just run as a daemon. No daemonization logic is needed either; use systemd --user, shell backgrounding, nohup, or other mechanisms to manage the process.

@waynew

This comment has been minimized.

Show comment
Hide comment
@waynew

waynew Sep 27, 2016

I think the most low-hanging fruit for alarms would be to have khal interactive alert every so often. I don't know exactly how the UI is implemented, but it seems like that would be a reasonable approach.

My personal needs would be fine with that approach.

waynew commented Sep 27, 2016

I think the most low-hanging fruit for alarms would be to have khal interactive alert every so often. I don't know exactly how the UI is implemented, but it seems like that would be a reasonable approach.

My personal needs would be fine with that approach.

@geier

This comment has been minimized.

Show comment
Hide comment
@geier

geier Sep 28, 2016

Member

feel free to send an PR :)

Member

geier commented Sep 28, 2016

feel free to send an PR :)

@teto

This comment has been minimized.

Show comment
Hide comment
@teto

teto Sep 28, 2016

I don't think it's much easier and also it would mean having the UI open at all times ? not very practical.

teto commented Sep 28, 2016

I don't think it's much easier and also it would mean having the UI open at all times ? not very practical.

@waynew

This comment has been minimized.

Show comment
Hide comment
@waynew

waynew Sep 29, 2016

If you use tmux (or screen) like I do then it's perfectly practical. Otherwise I'm not sure precisely what you'd use for notifications.

waynew commented Sep 29, 2016

If you use tmux (or screen) like I do then it's perfectly practical. Otherwise I'm not sure precisely what you'd use for notifications.

@mathstuf

This comment has been minimized.

Show comment
Hide comment
@mathstuf

mathstuf Sep 29, 2016

Have it send a notification over D-Bus and if the required modules aren't available or the config disables it, output to stdout for processing by any tool.

mathstuf commented Sep 29, 2016

Have it send a notification over D-Bus and if the required modules aren't available or the config disables it, output to stdout for processing by any tool.

@geier geier changed the title from VALARM support to Alarm user on alarm May 23, 2017

@geier

This comment has been minimized.

Show comment
Hide comment
@geier

geier May 23, 2017

Member

renamed, as we actually support editing VALARMs now.

Member

geier commented May 23, 2017

renamed, as we actually support editing VALARMs now.

@WhyNotHugo

This comment has been minimized.

Show comment
Hide comment
@WhyNotHugo

WhyNotHugo May 24, 2017

Member

I wonder if khal is the right place, or if maybe a separate app could monitor alarms on a vdir and show a generic notification.

I'm thinking about todoman, and how the alarms are basically identical, and a daemon/app/whatever to notify about both might save up work (and help dedupe effort).

Member

WhyNotHugo commented May 24, 2017

I wonder if khal is the right place, or if maybe a separate app could monitor alarms on a vdir and show a generic notification.

I'm thinking about todoman, and how the alarms are basically identical, and a daemon/app/whatever to notify about both might save up work (and help dedupe effort).

@mathstuf

This comment has been minimized.

Show comment
Hide comment
@mathstuf

mathstuf May 24, 2017

IMO, Todo and calendar apps are completely different things. Calendars document things that happen while Todo lists document things to be done. They require different logic to handle properly. Personally I use taskwarrior since it supports more complex queries and attributes than iCal does. To that end, I don't think these things should be conflated just because they both need to notify a user. An alarm for an event is usually set in time for me to get to an event while a task for that event may require subtasks, a week of lead time, and resulting "products".

mathstuf commented May 24, 2017

IMO, Todo and calendar apps are completely different things. Calendars document things that happen while Todo lists document things to be done. They require different logic to handle properly. Personally I use taskwarrior since it supports more complex queries and attributes than iCal does. To that end, I don't think these things should be conflated just because they both need to notify a user. An alarm for an event is usually set in time for me to get to an event while a task for that event may require subtasks, a week of lead time, and resulting "products".

@WhyNotHugo

This comment has been minimized.

Show comment
Hide comment
@WhyNotHugo

WhyNotHugo May 24, 2017

Member

@mathstuf I meant that the file format for both alarms is the same (quite literally, by the way, since it's exactly the same spec). So my idea is basically:

Some for of daemon that reads alarms from vdirs:

  • Set a timer up for the alarm.
  • When the timer fires, show a notification.

If you're using a different task management app/format that should be no problem; this proposal has no ties to todoman [nor khal, for that matter], just to vdir+icalendar, which is the format both use.

Member

WhyNotHugo commented May 24, 2017

@mathstuf I meant that the file format for both alarms is the same (quite literally, by the way, since it's exactly the same spec). So my idea is basically:

Some for of daemon that reads alarms from vdirs:

  • Set a timer up for the alarm.
  • When the timer fires, show a notification.

If you're using a different task management app/format that should be no problem; this proposal has no ties to todoman [nor khal, for that matter], just to vdir+icalendar, which is the format both use.

@mathstuf

This comment has been minimized.

Show comment
Hide comment
@mathstuf

mathstuf May 24, 2017

Ah, that sounds suitable then.

mathstuf commented May 24, 2017

Ah, that sounds suitable then.

@WhyNotHugo

This comment has been minimized.

Show comment
Hide comment
@WhyNotHugo

WhyNotHugo May 25, 2017

Member

@geier @untitaker How do you feel about this idea? I can get a proof-of-concept at some point. :)

Member

WhyNotHugo commented May 25, 2017

@geier @untitaker How do you feel about this idea? I can get a proof-of-concept at some point. :)

@geier

This comment has been minimized.

Show comment
Hide comment
@geier

geier May 25, 2017

Member

Have at it if you want, I don't see myself using something like that at the moment, but who knows, I also thought colored days were useless and now I use them all the time.

Member

geier commented May 25, 2017

Have at it if you want, I don't see myself using something like that at the moment, but who knows, I also thought colored days were useless and now I use them all the time.

@vodan

This comment has been minimized.

Show comment
Hide comment
@vodan

vodan Nov 2, 2017

Hi all, can somebody tell me the status of notifications. Is currently somebody working on this topic?

vodan commented Nov 2, 2017

Hi all, can somebody tell me the status of notifications. Is currently somebody working on this topic?

@untitaker

This comment has been minimized.

Show comment
Hide comment
@untitaker

untitaker Nov 2, 2017

Member
Member

untitaker commented Nov 2, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment