Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Settings page: easier to read and understand (look, wording, layout examples, times; low priority)

オープン
  • 何か問題がありますか？
#261 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
活発
技術スタック
css, html
領域
frontend

調査の方向性

Start with src/paperpi/web/templates/settings.html and src/paperpi/web/static/style.css, and read docs/decisions/web-interface.md for the limits: server-built pages, plain CSS, no build step, no JavaScript framework, and it must work on a phone. Work out the group headings, the separation between settings, and the key-on-the-left layout, and reword the shared help texts that mention the config file, giving the settings page its own wording. Done when the maintainer finds the page easy to read in a demo, with before/after screenshots and the design sources listed in the PR.

索引モデルが issue の本文から書いたものです。

説明

area:web enhancement

Low priority. Seen in the web interface demo (2026-10-10).

Problem: the plugin settings page (/plugins/<n>/settings, M5 part 3a) is hard to read: the groups don't stand out, the settings run into each other, and the setting's key (lat, display_time, ...) is at the end of the help text.

Wanted:

  • clearer, bolder group headings ("Settings of this plugin", "When and how it is shown", "More settings")
  • better separation between settings
  • the setting's key on the left, its field and help next to or below it
  • base the design on common good practice for settings pages (for example the layout of well-known settings screens and form design guides) rather than inventing our own; list the sources used in the PR

Also (follow-up from part 3a): some shared help texts were written for the config file ("see Layouts above", "leave it out to use ...") and read oddly on the page; give the page its own short wording where needed.

Limits: server-built pages and plain CSS, no build step and no JavaScript framework (docs/decisions/web-interface.md); must work on a phone.

Where: src/paperpi/web/templates/settings.html, src/paperpi/web/static/style.css.

Done when: txoof finds the page easy to read in a demo; before/after screenshots in the PR.

More wanted (txoof, 2026-10-10, after the Library pictures demo of #265):

  • Layout examples: a folded area (opens when clicked) under the layout choice that shows each of the plugin's layouts as an example picture, drawn with the sample data at the screen's size. The Library pictures (#265, web/pictures.py) can be reused: draw one picture per layout instead of only the first.
  • "When it is shown" (level): the label "When it is shown: alert, interrupt or rotation" is unclear. Give each choice a plain label and one line that says what it does, for example "Takes turns with the other plugins" (rotation), "Shown right away when it has news, then the turns go on" (interrupt), "Stays on the screen until it is dismissed" (alert). Check the exact behaviour in scheduler.py before writing the texts.
  • "Which layout": the help text ("Which layout (see "Layouts" above). Leave it out to use the first") was written for the config file. On the page it should read something like "Layout: how the information is arranged on the screen", with the layout names in the choice list and the examples above.
  • Times in human units: "Seconds on screen per turn" (display_time) and other times in seconds (refresh, alert_reminder, alert_max_time) show numbers like 604800 that mean little to most people. Use a slider (or a choice list) with steps that grow: 1–60 seconds, then 5, 10, 15, 30, 60 minutes, then 1, 2, 4, 8, 16, 24 hours (and days where a setting allows it). Show the value as words ("2 hours"). The config file keeps seconds. To decide when starting: which settings get it, the exact steps, what happens with a value from the config file that is not one of the steps (show it as it is, e.g. "7 minutes 30 seconds"), and how it works without JavaScript.

Size: this probably needs two PRs, each based on main: (1) look and wording, (2) layout examples and the time control. Plan the split before coding.

主要言語
Python
スター
205
フォーク
17
平均マージ
6時間 13分
マージ済み PR（30日）
39

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

txoof/PaperPi のほかの issue

txoof/PaperPi の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。