Jean-Luc Makiola
aa24de443d
Long-press an event block in the week or day timeline and drag it to another time or day column; drag a chip in the month grid onto another date. The drop runs through the edit screen's own write path, so recurring writes, reminders and guests behave the same as a save. Two provider traps the drag had to close: - RRULE is written verbatim while DTSTART moves, so dragging a FREQ=WEEKLY;BYDAY=MO occurrence to a Wednesday under "all events" left a Wednesday anchor under a Monday rule and the series stayed put. realignRecurrence re-derives BYDAY/BYMONTHDAY/BYMONTH, and refuses rules one moved occurrence can't resolve (BYDAY=MO,WE, 2TH, BYSETPOS) — those may only move the single occurrence. - Nothing below the UI refuses a write, so allowsEventMove gates the gesture. Not isEventTarget: a managed contact-mirror event is editable but must never move. The pickup is hand-rolled rather than detectDragGesturesAfterLongPress: during the 500ms hold the block consumes nothing, so the scroll and page swipe claim at touch slop and kill the press, and the stock detector also cancels as soon as the finger leaves a block that may only be 10dp tall. Ours holds with a 6dp tolerance and never cancels on leaving bounds. Agenda is out of scope (list rows, no positioned blocks), as is resize-by-edge-drag. Month drags don't auto-scroll or page yet.
Documentation map
Where to look for what:
| Document | What it is |
|---|---|
../CONTRIBUTING.md |
How to contribute: issue-first workflow, which branch to target, translations, the rules a change is reviewed against |
BUILDING.md |
Building from source: submodule, JDK/SDK requirements, Gradle tasks, what CI runs |
ARCHITECTURE.md |
Orientation tour: principles, layers, navigation, recurring-write / conflict / reminder pipelines, testing |
RELEASING.md |
Release process: versioning, the merge-driven pipeline, the two-forge split, secrets, key custody |
../CHANGELOG.md |
Release history (Keep a Changelog, SemVer) |
| Issues + milestones | The roadmap. What's planned, in progress, and shipped — a milestone maps to its release/vX.Y.Z branch |
../.planning/PROJECT.md |
What the project is: core value, stack + version pins, constraints, naming, forge/release infrastructure |
design/ |
Per-feature design notes kept for features whose provider behaviour is worth recording |
../fastlane/metadata/android/ |
Store metadata (single source of truth): descriptions, title, icon, screenshots (DE + EN). Harvested directly by the official F-Droid repo; transformed into the self-hosted repo layout at release time by ../scripts/fastlane_to_fdroid_localized.sh |
../fdroid-metadata/ |
App-level F-Droid control file (*.yml: Categories, License, links) for the self-hosted repo's fdroid update |
fdroid-official/ |
Recipe + notes for publishing to the official F-Droid repo (reproducible build + developer-signed binary) |
Conventions: planning lives in the issue tracker, not in this repository. The
.planning/ files that predated it (a roadmap, a development-state snapshot, and
a per-milestone requirement checklist) are gone — issues and milestones say the
same thing without going stale. PROJECT.md is what remains, and it describes
the project rather than its plan.
ARCHITECTURE.md is the authoritative orientation tour: it is updated with the
code, and is the right place for a lesson learned about the calendar provider.