docs: add custom widget subclassing guide - #434
Merged
Merged
Conversation
Contributor
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
forntoh
added a commit
that referenced
this pull request
Sep 28, 2026
## Summary - Removes the dangling esp8266 `include` block from the Compile Examples workflow matrix. ## Why Since bbd2b8f ("Remove esp8266 board configuration from compile workflow") removed the esp8266 matrix board entry, the leftover `include` block (no `fqbn`, empty `libraries`/`sketch-paths`) has spawned a broken esp8266 job on every workflow run — it fails with `IndexError: list index out of range` before compiling anything (see the failed job on #433 and #434). That commit's own verification run was cancelled, so the breakage went unnoticed. This completes the original removal intent and un-breaks the compile workflow for all current and future PRs. ## Verification - `git diff`: only the 9-line esp8266 include block removed; the four board matrix entries (esp32, avr:uno, mkr1000, stm32) and all remaining include blocks (AVR, ESP32, SAMD, STM32) are untouched. - YAML validated: `yaml.safe_load` (temp venv) and independently via ruby `YAML.load_file` — both pass. ## Notes - If the esp8266 compile job is listed as a required status check in branch protection, that repository setting should be updated after this merges. - After this merges, open PRs with a recorded failed esp8266 job (e.g. #433) may need a branch update to re-run checks. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Automated build validation no longer includes ESP8266 board configurations. This changes which board builds are checked automatically; it does not describe a change to the behavior of existing devices. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
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
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.
Summary
overview/widgets/custom-widget) describing the supported pattern for customizing how widget values are displayed: subclass an existing widget (orBaseWidgetValue<T>), override the protected virtualdraw()method, and compose the custom widget withITEM_WIDGETinstead of theITEM_RANGE/ITEM_LISTconvenience macros.stringForValue(const T&)function instead of a printf format string, keeping all inherited editing behavior (UP/DOWN, clamping, cycling, BACK restore).Motivation
Documents the pattern that answers #430 (dynamic string for widget values) without any library API change. A maintainer reply with the same pattern has already been posted on the issue: #430 (comment)
Verification
make html, clean rebuild): succeeds with the pre-existing warning set only — byte-identical to a clean build before the change; zero warnings from the new page.BaseWidget::draw(protected virtual,src/widget/BaseWidget.h),BaseWidgetValue::draw/WidgetRange::draw/WidgetList::drawbehaviors (including thatWidgetList::drawformats the selected list entry),ITEM_DRAW_BUFFER_SIZE(64), andITEM_WIDGETcomposition/template deduction (src/ItemWidget.h).References #430
Summary by CodeRabbit