feat(capi): speed percent honours engine range; resets emit buffer-clear event - #55
Merged
Merged
Conversation
…ear event Two engine-side fixes behind the v6 first-impressions report (see Dasher-GTK #51 and governance RFC 0005/0015 discussion): - dasher_set_speed_percent clamped to a fixed 20-400 (raw 32-640), silently truncating the top of Dasher v5's speed range (v5 allowed raw 10-800, i.e. up to 500 percent). The clamp now derives from the engine's declared LP_MAX_BITRATE bounds (raw 1-1000 -> ~1-625 percent), so frontends using the percent helper can no longer lose v5 speeds. - dasher_reset, dasher_reset_output_text and dasher_set_alphabet_id clear the edit buffer without any insert/delete deltas, forcing every frontend to know this and re-sync shadow buffers by hand (Dasher-GTK's output pane kept stale text after New). They now emit output event type 2 (buffer clear, empty text) so subscribers can clear their copy. Additive: existing callbacks that switch on 0/1 are unaffected. Docs updated in dasher.h and C_API.md; tests extended in test_capi.cpp, test_capi_extended.cpp, and test_parameters.cpp (whose old 20-400 assertions encoded the replaced contract). Signed-off-by: will wade <willwade@gmail.com>
This was referenced Aug 21, 2026
willwade
added a commit
to dasher-project/Dasher-Android
that referenced
this pull request
Aug 22, 2026
#14) Fixes #13. ## Problem The speed stepper coerced to a fixed **20–400 %** (`MainActivity.kt` speed steppers). Dasher v5's UI allowed raw `MaxBitRateTimes100` 10–800 (6–500 %) and long-term users sit at the top of the range — a v5 user at 5.0× (raw 500) cannot reach their speed. Two layers caused it: 1. The UI hardcoded 20/400. 2. The engine's `dasher_set_speed_percent` also clamped to 20–400 — fixed engine-side in [DasherCore #55](dasher-project/DasherCore#55), released as [v0.2.3](https://github.com/dasher-project/DasherCore/releases/tag/v0.2.3). ## Changes - `DasherEngine.speedRangePercent()`: derives the percent bounds from the engine's `LP_MAX_BITRATE` manifest entry (raw 1–1000 → ~1–625 %), historic 20–400 only as fallback. - `MainActivity`: `speedRange` state initialised from the engine once realised; steppers coerce to it. - `NativeBridge` doc comment updated to describe the engine-range clamp. - Submodule `third_party/DasherCore` → **v0.2.3** (also brings output event type 2 — buffer-clear — unused here for now; the IME's per-char handler ignores unknown types, verified). ## Cross-repo context - Same fix family as [Dasher-GTK #51](dasher-project/Dasher-GTK#51) and the [governance RFC 0005 parity notes](dasher-project/governance#28) ("speed controls must accept the full v5 range"). - Sibling issues: Dasher-Windows #27, Dasher-Apple #34. ## Testing - `:app:compileDebugKotlin` + `:app:testDebugUnitTest` + `:app:assembleDebug` (native build vs v0.2.3 for arm64-v8a + x86_64) all green locally. - Manual check on-device/emulator recommended: stepper reaches 500 % and `getSpeedPercent` round-trips it. DCO signed. Signed-off-by: will wade <willwade@gmail.com>
willwade
added a commit
to dasher-project/Dasher-Apple
that referenced
this pull request
Aug 24, 2026
…#36) Fixes #34. ## What - **DasherCore submodule → v0.2.4**, which contains [DasherCore #55](dasher-project/DasherCore#55): `dasher_get_speed_percent` no longer pre-clamps to raw 32–640, and `dasher_set_speed_percent` clamps to the engine's declared `LP_MAX_BITRATE` manifest range instead of 20–400 % - New `DasherBridge.speedRangePercent` on **all four targets** (macOS, iOS app, iOS keyboard, visionOS): reads `LP_MAX_BITRATE` min/max from the parameter manifest and converts raw → percent (raw 160 = 100 % ⇒ raw 1–1000 ≈ 1–625 %), falling back to the historic 20–400 if the manifest is unavailable - The four view models' steppers now clamp with those bounds ## Why Issue #34: every target clamped to 20–400 %, below v5's 500 % top; migrated v5 users above 4.0× couldn't even display their speed. Mirrors [Dasher-Android #14](dasher-project/Dasher-Android#14) and [Dasher-GTK #51](dasher-project/Dasher-GTK#51). ## Notes - Kept the manual `outputText` re-syncs after `reset()` — the optional event-type-2 simplification from the issue can ride a later PR - Verified: `xcodebuild -scheme DasherMac` (CI gate) — **BUILD SUCCEEDED**, 0 errors Signed-off-by: will wade <willwade@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cross-platform follow-up to Dasher-GTK #51 and the governance RFC 0005 parity notes. Two behaviours turned out to be engine-side, affecting every frontend:
1.
dasher_set_speed_percenttruncated v5's top speedsThe helper clamped to a fixed 20–400 % (raw
LP_MAX_BITRATE32–640). Dasher v5 allowed raw 10–800 — up to 500 % — and long-time users sit at the top of that range (Steve Saling's config: 700 raw). Every frontend that uses the percent helper (Windows VM, macOS/iOS/visionOS ±10 steppers, Android's 20–400 coerce) inherits the cap, and a migrated raw value gets silently knocked down on the first nudge.Fix: the clamp now derives from the engine's own declared
LP_MAX_BITRATEbounds viaparameter_defaults(raw 1–1000 → ~1–625 %). 500 % (v5's max) round-trips exactly; out-of-range values clamp to the manifest range.2. Resets cleared the buffer with no event — stale shadow buffers
dasher_reset,dasher_reset_output_textanddasher_set_alphabet_idwipe the edit buffer without insert/delete deltas, so every frontend maintaining a shadow buffer must know this and re-sync manually. Dasher-GTK's output pane kept stale text after New (fixed app-side there, but the trap remains for every frontend).Fix: those calls now emit output event type 2 (buffer clear, empty
text). Additive — existing callbacks that handle 0/1 and ignore unknown types are unaffected (verified: DasherCore's own tests and all shipped frontends switch on the type).Docs + tests
dasher.handC_API.mdupdated (event table, speed range notes)reset_emits_buffer_clear_event(test_capi_extended), speed-range assertions incl. exact 500 % round-trip (test_capi, test_parameters)test_parameters.cppold 20–400 assertions encoded the replaced contract — updated with a commentgit clang-formatclean vs mainFrontend follow-ups (not in this PR)
Windows/macOS/iOS/visionOS/Android steppers clamp at 400 in their own UI — those need their own range updates now the engine accepts more; tracked via governance RFC 0005's new parity section.
DCO signed.