Summary
Calendar integration is currently a first-class experience on macOS but missing on Windows.
On macOS, Tuttle talks directly to the system calendar via a native EventKit bridge (tuttle/eventkit_bridge.py): a compiled Swift helper app handles permission prompts, calendar listing, and event fetching, so time tracking "just works" against the user's real calendars.
On Windows, none of that exists — is_available() in eventkit_bridge.py simply returns False on non-Darwin platforms, and listing/fetching return empty results. Windows users fall back to manually importing .ics files (tuttle/calendar.py → ICSCalendar, wired up in tuttle/app/timetracking/data_source.py), which means:
- No live sync — you must re-export and re-import the
.ics file every time events change
- No calendar discovery — you have to locate and export each calendar yourself
- The workflow is undocumented and error-prone for non-technical users
Scope: this issue is about local calendar integration only (the calendar data already on the user's machine). Network-based sync (e.g. CalDAV) is out of scope — that would be a separate, cross-platform feature.
Related: #493 (Linux local calendar support)
Goals
Possible approaches (to be discussed)
- Windows Appointments API (
Windows.ApplicationModel.Appointments) — the WinRT API backing the built-in Calendar app; accessible from Python via winsdk/winrt bindings, with a system-mediated permission prompt similar to EventKit
- Outlook COM automation — for users whose calendar lives in desktop Outlook
- Thunderbird's local storage — read the calendar data Thunderbird already caches locally
- Watched
.ics files/folders — auto-reload local .ics files when they change, as a lightweight stopgap that works regardless of the user's calendar app
Feedback wanted — Windows users, we need you
We don't want to design this in a vacuum. If you use Tuttle (or want to) on Windows, please share:
- Which calendar app do you use? (Windows Calendar / New Outlook, classic Outlook, Thunderbird, plain
.ics files, …)
- Where does your local calendar data actually live?
- Which approach above would work best for your setup? Or is there one we missed?
- What's the minimum viable workflow for you? (e.g. "auto-reloading a local
.ics file would already be enough")
Your input will directly shape which approach we implement first.
Summary
Calendar integration is currently a first-class experience on macOS but missing on Windows.
On macOS, Tuttle talks directly to the system calendar via a native EventKit bridge (
tuttle/eventkit_bridge.py): a compiled Swift helper app handles permission prompts, calendar listing, and event fetching, so time tracking "just works" against the user's real calendars.On Windows, none of that exists —
is_available()ineventkit_bridge.pysimply returnsFalseon non-Darwin platforms, and listing/fetching return empty results. Windows users fall back to manually importing.icsfiles (tuttle/calendar.py→ICSCalendar, wired up intuttle/app/timetracking/data_source.py), which means:.icsfile every time events changeScope: this issue is about local calendar integration only (the calendar data already on the user's machine). Network-based sync (e.g. CalDAV) is out of scope — that would be a separate, cross-platform feature.
Related: #493 (Linux local calendar support)
Goals
.icsexportsPossible approaches (to be discussed)
Windows.ApplicationModel.Appointments) — the WinRT API backing the built-in Calendar app; accessible from Python viawinsdk/winrtbindings, with a system-mediated permission prompt similar to EventKit.icsfiles/folders — auto-reload local.icsfiles when they change, as a lightweight stopgap that works regardless of the user's calendar appFeedback wanted — Windows users, we need you
We don't want to design this in a vacuum. If you use Tuttle (or want to) on Windows, please share:
.icsfiles, …).icsfile would already be enough")Your input will directly shape which approach we implement first.