Skip to content

fix(hello-world): centre the text, and always pass the configured colour - #380

Open
ChuckBuilds wants to merge 1 commit into
mainfrom
fix/hello-world-centering
Open

fix(hello-world): centre the text, and always pass the configured colour#380
ChuckBuilds wants to merge 1 commit into
mainfrom
fix/hello-world-centering

Conversation

@ChuckBuilds

Copy link
Copy Markdown
Owner

Thirteenth plugin in the README pass — and two bugs in the plugin that new plugins are copied from, which is what makes them worth more than their size.

The default message did not fit the default panel

draw_text treats x as the left edge unless centered=True is passed. The plugin passed x=width // 2 without it, under a comment reading "Calculate positions for centered text". So "Hello, World!" began at the midpoint of a 128-wide panel and ran off the right:

BeforeHello, Worl, starting at x=64:

the text began mid-panel and was clipped by the right edge

After — centred and complete. The hero image in the README is the fixed render.

The harness could not catch this. PIL clips at draw time, so the drawn bounding box stays inside the panel and the overflow check sees nothing — check_plugin.py reports 8/8 PASS both before and after. It was only visible by looking at the output, which is exactly what generating README screenshots does.

A configured colour was silently ignored on real installs

Each draw_text call branched on whether the font manager returned a face, and the font-manager branch omitted color:

if message_font:
    draw_text(self.message, x=..., y=..., font=message_font)   # no colour
else:
    draw_text(self.message, x=..., y=..., color=self.color, font=self.bdf_font)

On any install with a font manager — the normal case on a Pi — the message drew white regardless of color.

Worth noting how close I came to missing this: my own hash-check passed the colours, because the test harness supplies no font manager, so the else branch ran. The check said "colour works" and it does, but only in the environment I was checking in. Reading the branch is what caught it.

Both branches are collapsed — font=message_font or self.bdf_font with the colour passed either way — which also halves the code.

Why this one matters beyond itself

CLAUDE.md says new plugins start from hello-world. Both mistakes are the kind that propagate silently into every plugin copied from it, so the README's template section now calls them out explicitly:

  • draw_text(x=...) is the left edge — omit x to auto-centre, or pass centered=True
  • pass color on every draw_text call, never in only one branch

Audits

  • Config tokens: none dropped; 6/6 schema leaves documented, all six verified to change the render
  • Old section list read by hand — caught that I'd dropped the Examples block; restored
  • All four core doc links verified to exist before carrying them over
  • check_plugin.py — 8/8 PASS; render_docs_assets --check — images match
  • manifest bumped 1.0.3 → 1.1.0 (minor: rendering changes visibly)

🤖 Generated with Claude Code

Two bugs in the plugin new plugins are copied from, which is what makes them
worth more than their size.

draw_text treats x as the LEFT edge unless centered=True is passed. The plugin
passed x=width // 2 without it, under a comment reading "Calculate positions
for centered text" -- so the default "Hello, World!" began at the midpoint of a
128-wide panel and ran off the right, rendering as "Hello, Worl". The default
message did not fit the default panel.

The harness could not catch it: PIL clips at draw time, so the drawn bounding
box stays inside the panel and the overflow check sees nothing. check_plugin
reports 8/8 PASS both before and after this change. It is only visible by
looking at the output, which is what generating the README screenshots did.

Separately, each draw_text call branched on whether the font manager returned a
face, and the font-manager branch omitted color. On any install where a font
manager is present -- which is the normal case on a Pi -- a configured colour
was silently ignored and the text drew white. My own hash check passed the
colours here only because the test harness supplies no font manager, so the
else branch ran. The branches are collapsed: the face is chosen with
`font=message_font or self.bdf_font` and the colour is passed either way, which
also halves the code.

The README documents all six settings with real renders and calls out both
pitfalls in the template section, since a new plugin copied from here would
otherwise inherit them. It also keeps the old file's examples, template file
table and core doc links -- all four links verified to exist.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 9d31a7c8-046c-4fb5-b39d-bc0d4d618460


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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@codacy-production

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric Results
Complexity 0

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant