Drag the date range on the axis it is chosen from

The range could be turned on with a finger and not aimed with one. Its two
ends were typed as `YYYY-MM-DD` into 108px fields behind a soft keyboard, to
name days already drawn on the axis a thumb away; and the chip that seeds them
takes its span from the timeline's zoom and pan, which are a wheel and a middle
button. A touch screen has neither, so on Android the filter was a switch with
no aim.

The band is now on the timeline. Two ends with grips, dragged along the bars,
released to filter — the histogram was already how a period is found, and this
makes it how a period is stated. Both ends snap to whole days, which is what
the typed fields mean, what `show_range` reads back out, and a floor under a
range dragged shut. The fields stay for what dragging cannot do: name an exact
day, and say in words what the range is.

For that to work the axis had to stop following the range. Redrawn to the band,
it moved the ground under the very handles doing the narrowing, and there was
nothing outside the range left to widen back into.

While there: a fixed number of equal bins instead of calendar buckets. Between
one calendar unit and the next the bar count is free to wander by a factor of
twelve, so zooming in halved it two steps out of three — the same picture drawn
wider until it jumped back to fine. Equal bins also include the empty ones, so
a bar's position on the track and the date under it are finally the same
quantity; before, a library with gaps drew a February six months wide and the
marker, the band and a click all pointed somewhere else. The count is a
setting, 32 or 64, because the right answer is a question about the screen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

core/dr-catalog/src/lib.rs

@@ -134,6 +134,19 @@ impl Granularity {
     /// about 48 months — and on a linear measure the larger count always looks
     /// further away, which would bias every choice towards too few bars.
     pub fn for_span(seconds: i64) -> Self {
+        Self::for_bucket(seconds.max(1) / Self::TARGET_BARS)
+    }
+
+    /// The calendar unit nearest a bucket of `seconds`, for *labelling* one.
+    ///
+    /// Split out from [`Self::for_span`] because the axis no longer buckets by
+    /// calendar unit at all — it divides the visible span into a fixed number
+    /// of equal bins (see `LibrarySettings::timeline_bars`). What is still
+    /// wanted is the unit a bin is closest to, so a bin of about a day is
+    /// labelled as a date and one of about a year as a year. Asked directly
+    /// rather than derived from the span, because the bin count is now the
+    /// user's rather than this module's target.
+    pub fn for_bucket(seconds: i64) -> Self {
         let seconds = seconds.max(1) as f64;
         // Finest first, so that when two options are equally far from the
         // target the finer one wins: `min_by` keeps the first minimum it saw,
@@ -147,15 +160,14 @@ impl Granularity {
         .into_iter()
         .min_by(|a, b| {
             let cost = |g: Granularity| {
-                let bars = seconds / g.approx_seconds() as f64;
-                // How far off the target, measured multiplicatively: twice as
-                // many and half as many are equally wrong.
+                // How far off, measured multiplicatively: twice as long and
+                // half as long are equally wrong.
                 //
-                // Deliberately not clamped to at least one bar. A span shorter
-                // than a bucket scores *worse* the coarser the bucket, which is
-                // what makes an hour of photographs pick hourly bars instead of
-                // every option tying at "one bar" and the coarsest winning.
-                (bars / Self::TARGET_BARS as f64).ln().abs()
+                // Deliberately not clamped. A bucket shorter than the unit
+                // scores *worse* the coarser the unit, which is what makes an
+                // hour of photographs pick hourly bars instead of every option
+                // tying at "one bucket" and the coarsest winning.
+                (seconds / g.approx_seconds() as f64).ln().abs()
             };
             cost(*a)
                 .partial_cmp(&cost(*b))

core/dr-types/src/lib.rs

@@ -17,7 +17,7 @@ pub use colour::{Chromaticities, Transfer};
 pub use selector::{ColourLabel, DateSelector, FlagState, Selector, Tier};
 pub use settings::{
     CacheSettings, CollisionPolicy, ColourSpace, DevelopSettings, ExportFormat, ExportSettings,
-    ExportTarget, ImportSettings, OutputSharpening, Settings, SizingMode,
+    ExportTarget, ImportSettings, LibrarySettings, OutputSharpening, Settings, SizingMode,
 };
 pub use time::{
     civil_from_unix, civil_from_unix_at, format_date, parse_date, unix_from_civil, Civil,

core/dr-types/src/settings.rs

@@ -53,6 +53,60 @@ pub struct Settings {
     pub export: ExportSettings,
     pub develop: DevelopSettings,
     pub import: ImportSettings,
+    pub library: LibrarySettings,
+}
+
+// ---------------------------------------------------------------------------
+// Library
+// ---------------------------------------------------------------------------
+
+/// TRACES: FR-CAT-6
+/// How the library view is drawn, where the answer depends on the screen
+/// rather than on the photographs.
+#[derive(Debug, Clone, PartialEq, Serialize, Deserialize)]
+#[serde(default)]
+pub struct LibrarySettings {
+    /// How many bars the capture-time axis is divided into.
+    ///
+    /// **A fixed count, not a bucket size.** The axis used to bucket by
+    /// calendar unit — year, month, day, hour — and take whichever came
+    /// nearest a target count. Between two of those units the count is free to
+    /// wander by a factor of twelve or thirty, so zooming in halved the number
+    /// of bars two steps out of three: the same picture drawn wider, until it
+    /// suddenly jumped back to fine. Dividing the visible span into a fixed
+    /// number of equal bins makes every zoom step show the same amount of
+    /// detail at a finer scale, which is what zooming is for.
+    ///
+    /// It also makes the axis linear in *time*. Calendar buckets are only
+    /// emitted where photographs exist, and the widget gives each bar an equal
+    /// slot, so a library with gaps drew a February that was six months wide.
+    /// Equal bins include the empty ones, so a bar's position on the track and
+    /// the date under it are the same quantity — which is what lets the range
+    /// band and the position marker be drawn on the same axis as the bars.
+    ///
+    /// Why it is a setting: the right number is a question about the screen.
+    /// 64 bars on a phone held in the hand is finer than a finger can aim at;
+    /// 32 on a desktop monitor wastes most of a tall sidebar.
+    pub timeline_bars: u32,
+}
+
+impl LibrarySettings {
+    /// The counts the settings page offers.
+    ///
+    /// Two, both powers of two, and far enough apart that the difference is
+    /// visible. A free number would be a control the user has to experiment
+    /// with to understand, for a choice with exactly two sensible answers:
+    /// one bar per finger-width on a phone, twice that where there is room.
+    pub const BAR_CHOICES: [u32; 2] = [32, 64];
+}
+
+impl Default for LibrarySettings {
+    fn default() -> Self {
+        // The coarser of the two. A bar has to be wide enough to hit with a
+        // finger before it has to be narrow enough to be precise, and the
+        // smallest screen is the one where getting this wrong hurts most.
+        Self { timeline_bars: 32 }
+    }
 }
 
 // ---------------------------------------------------------------------------
@@ -709,6 +763,18 @@ impl Settings {
     pub fn sanitise(&mut self) {
         self.export.quality = self.export.quality.clamp(1, 100);
 
+        // Snapped to an offered count rather than clamped to a range. The
+        // settings page lights the chip whose value matches, so a
+        // hand-edited 40 would leave every chip dark and the page unable to
+        // say what the axis is currently doing.
+        if !LibrarySettings::BAR_CHOICES.contains(&self.library.timeline_bars) {
+            let wanted = self.library.timeline_bars;
+            self.library.timeline_bars = LibrarySettings::BAR_CHOICES
+                .into_iter()
+                .min_by_key(|n| n.abs_diff(wanted))
+                .unwrap_or(LibrarySettings::default().timeline_bars);
+        }
+
         // A zero-pixel or zero-percent export produces no image. Nudged to the
         // smallest thing that does, rather than back to the default: the user
         // clearly wanted "small", and silently restoring 2048 would ignore
@@ -1050,6 +1116,38 @@ mod tests {
         assert_eq!(s.export.quality, 1);
     }
 
+    #[test]
+    fn every_bar_count_can_be_chosen_on_the_page() {
+        // The page draws one chip per choice and lights the one that matches,
+        // so a default outside the list would leave every chip dark.
+        assert!(LibrarySettings::BAR_CHOICES.contains(&LibrarySettings::default().timeline_bars));
+    }
+
+    #[test]
+    fn sanitise_snaps_a_hand_edited_bar_count_to_an_offered_one() {
+        // The file is hand-editable and the page cannot show a count it does
+        // not offer. Snapped to the nearest rather than reset to the default:
+        // someone who wrote 60 wanted the finer axis, and 32 would ignore that.
+        let mut s = Settings::default();
+        s.library.timeline_bars = 60;
+        s.sanitise();
+        assert_eq!(s.library.timeline_bars, 64);
+
+        s.library.timeline_bars = 0;
+        s.sanitise();
+        assert_eq!(s.library.timeline_bars, 32);
+    }
+
+    #[test]
+    fn sanitise_leaves_an_offered_bar_count_alone() {
+        for n in LibrarySettings::BAR_CHOICES {
+            let mut s = Settings::default();
+            s.library.timeline_bars = n;
+            s.sanitise();
+            assert_eq!(s.library.timeline_bars, n);
+        }
+    }
+
     #[test]
     fn sanitise_rescues_a_zero_dimension() {
         let mut s = Settings::default();