I’ve been working on a little event/todo scheduling extension for Bike. Coming from org-mode, I wanted to be able to attach scheduled dates to my notes to be able to have my events and notes in one place, and so I wanted to show off what I built!
The main features of the extension are:
a schedule date picker that uses natural language parsing to figure out when a task should be scheduled (shoutout to the chrono library) and displays the scheduled date inline in the outline view;
support for recurring tasks (via the rrule library);
an agenda view that shows upcoming tasks and their relevant dates and times (with code almost entirely lifted from Jesse’s todos.bkext example)
Here’s a demo:
The code is available at GitHub - dcao/bike-mods · GitHub . I’m hoping to add some other features like iCal/EventKit integration and such too, but would love to hear folks’ feedback on this as well!
(and a final shoutout to Jesse for making Bike—it is an extremely pleasant piece of software to use and built on top of )
Thanks for doing and sharing! And keep in mind features/api that you would want to make it better.
It seems like dates/ranges should be a foundational objects in some form. It would be nice to have common foundation so that for example there could be interaction between Bike’s build in calendar and the dates you are assigning. Colored dots on calendar days, etc.
Oh sure! I think things that came to my mind as I was implementing:
If I wanted to add EventKit integration directly into the extension, I believe this would require the Bike app to allow request Calendar permissions—but I’m not sure if it’s worth changing the app to allow for hypothetical extension authors to do calendar interaction :^)
In general, it’d be helpful to have info in the documentation about where serialization might be happening across API boundaries. As an example, I was using the Temporal API (via a polyfill) in messages passed across my App/DOM protocol, but I didn’t realize that Bike was doing serialization/deserialization as the messages were being passed behind the scenes, so Temporal instances were being turned into regular plain JS objects as they moved across the protocol.
I was facing a similar issue when dealing with the Style API. The docs mention that mark objects are mutable across rules, but it seems like something else is going on—when I assign additional properties to mark objects, or when I assigned a non-string to the mark.contents.gravity field, those changes weren’t persisted. (Relatedly, it’d be nice to have some kind of mark.extra field for persisting this kind of info, rather than me doing funky things with mark.contents.gravity)
Generally, I’m curious how extensions could do background work on a separate thread? As an example, if I wanted to write a “inline render LaTeX” extension and I wanted my style extension to avoid having LaTeX rendering freeze up the main render thread, how would I go about that?
For bike.showChoiceBox, it’d be nice to get the text that was entered into the box if allowsEmptySelection is set to true.
)