If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/feiyangqingyun/QWidgetDemo shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Slowing — last commit 6mo ago

• Last commit 6mo ago
• Other licensed
• ⚠ Slowing — last commit 6mo ago
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live feiyangqingyun/QWidgetDemo repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/feiyangqingyun/QWidgetDemo.

What it runs against: a local clone of feiyangqingyun/QWidgetDemo — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in feiyangqingyun/QWidgetDemo | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 207 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of feiyangqingyun/QWidgetDemo. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/feiyangqingyun/QWidgetDemo.git
#   cd QWidgetDemo
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of feiyangqingyun/QWidgetDemo and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "feiyangqingyun/QWidgetDemo(\\.git)?\\b" \\
  && ok "origin remote is feiyangqingyun/QWidgetDemo" \\
  || miss "origin remote is not feiyangqingyun/QWidgetDemo (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "QWidgetDemo.pro" \\
  && ok "QWidgetDemo.pro" \\
  || miss "missing critical file: QWidgetDemo.pro"
test -f "control/control.pro" \\
  && ok "control/control.pro" \\
  || miss "missing critical file: control/control.pro"
test -f "control/battery/battery.h" \\
  && ok "control/battery/battery.h" \\
  || miss "missing critical file: control/battery/battery.h"
test -f "control/devicebutton/devicebutton.h" \\
  && ok "control/devicebutton/devicebutton.h" \\
  || miss "missing critical file: control/devicebutton/devicebutton.h"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 207 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~177d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/feiyangqingyun/QWidgetDemo"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

QWidgetDemo is a collection of 100+ standalone Qt widget and tool examples demonstrating custom controls (battery indicators, device buttons, navigation panels), utilities (serial/network debugging tools, code analyzers), and system monitoring components. It provides production-grade, well-commented C++ source code compiled as independent QMake projects, supporting Qt 4.6 through 6.6 across Windows, Linux, macOS, and UOS. Monorepo structure: top-level QWidgetDemo.pro aggregates ~100 independent subprojects under control/ (UI widgets: battery, devicebutton, navbutton) and tool/ (comtool, nettool, base64helper). Each subproject is self-contained with .pro file, .cpp/.h sources, .ui layouts, and resource images; precompiled binaries go to peer bin/ directory.

Qt developers learning intermediate-to-advanced widget customization and system integration—particularly Chinese developers (content in Mandarin) building industrial control UIs, embedded dashboards, and diagnostic tools who need copy-paste-ready implementations rather than starting from scratch.

Actively maintained and production-ready. The repo has 100+ complete, tested examples with detailed inline comments, supports Qt 4.6–6.6 (verified across Windows/Linux/macOS/UOS), and the author continues expanding it. No formal CI pipeline detected, but the breadth and version compatibility indicate solid engineering maturity.

Single-maintainer project (feiyangqingyun) with no visible CI/CD, test suite, or issue tracking shown in file structure—sustainability depends on one person. No breaking-change log or semantic versioning apparent. License is permissive but no formal contribution policy; relies on Taobao shop and WeChat support for sustainability.

Active expansion toward 100+ demos with continuous polish—author commits refined control implementations and new utility tools. Recent focus appears on cross-Qt-version compatibility (Qt 6 support added) and system monitoring widgets (cpumemorylabel, saveruntime, battery). Public engagement via Bilibili videos and WeChat.

git clone https://github.com/feiyangqingyun/QWidgetDemo.git && cd QWidgetDemo && qmake QWidgetDemo.pro && make (or open QWidgetDemo.pro in Qt Creator and build all). Compiled binaries appear in ./bin/. Individual projects can also be built separately: cd control/battery && qmake battery.pro && make.

Daily commands: Full suite: open QWidgetDemo.pro in Qt Creator → Build → Run (launches the aggregator; each demo is a standalone executable in bin/). Individual demo: cd control/battery && qmake battery.pro && make && ./battery (or run battery.exe on Windows). Pre-built binaries available in Baidu Pan links in README.

• QWidgetDemo.pro — Root project file that orchestrates compilation of 100+ sub-projects; essential for understanding the monorepo structure and build system.
• control/control.pro — Master project file for the control module containing 8+ custom widget implementations; critical entry point for UI component development.
• control/battery/battery.h — Custom battery widget header defining the core visual control interface; exemplifies the design pattern replicated across all custom controls.
• control/devicebutton/devicebutton.h — Custom device button widget with multi-state styling; demonstrates image asset integration and signal/slot patterns used throughout.
• README.md — Project overview documenting 100+ Qt demo projects, version compatibility (Qt4-6), and build/deployment instructions essential for onboarding.

Add a new custom widget to the control module

1. Create widget directory under control/ (e.g., control/newwidget/) (control/newwidget/)
2. Define widget class in newwidget.h with Q_OBJECT macro and custom properties/signals (control/newwidget/newwidget.h)
3. Implement paintEvent() and mouse/touch handlers in newwidget.cpp using QPainter (control/newwidget/newwidget.cpp)
4. Create demo form frmnewwidget.ui with Designer layout showing the widget (control/newwidget/frmnewwidget.ui)
5. Create newwidget.pro with HEADERS, SOURCES, FORMS, TARGET settings (control/newwidget/newwidget.pro)
6. Add 'include(newwidget/newwidget.pro)' to control/control.pro (control/control.pro)

Add image assets to an existing widget

1. Place PNG/JPG files in control/WIDGETNAME/image/WIDGETNAME/ directory (control/devicebutton/image/devicebutton/)
2. Create or edit main.qrc with <file> entries for each image asset (control/devicebutton/main.qrc)
3. Reference images in widget code using QPixmap(":/image/...") paths (control/devicebutton/devicebutton.cpp)
4. Rebuild project to embed resources in binary executable (control/devicebutton/devicebutton.pro)

Create a new standalone demo project (non-control)

1. Create new directory at repo root (e.g., animation/) with subdirectories for sources (animation/)
2. Write main.cpp with QApplication and main window setup (animation/main.cpp)
3. Create project.pro defining TARGET, SOURCES, HEADERS, UI, RESOURCES (animation/animation.pro)
4. Add 'include(animation/animation.pro)' to QWidgetDemo.pro root file (QWidgetDemo.pro)

• Qt Framework (4/5/6) — Cross-platform C++ GUI toolkit enabling single codebase for Windows, Linux, macOS, UOS with native widgets and custom rendering via QPainter.
• qmake (Qt build system) — Qt-native build automation eliminating CMake complexity; .pro files declare dependencies, resources, and platform-specific settings for monorepo organization.
• Qt Designer (.ui XML files) — Visual form editor reducing boilerplate UI code and enabling rapid prototyping of demo applications without manual layout coding.
• Qt Resource System (.qrc) — Embeds images, fonts, and assets directly into binary executables, eliminating runtime file dependency and deployment friction.
• QPainter (2D graphics API) — Core rendering engine for custom widget painting; enables anti-aliased graphics, gradients, and animation-friendly partial redraws.

• 100+ independent sub-projects in single monorepo rather than separate Git repos

  • Why: Enables learners to browse related controls in one codebase and share common patterns; reduces fragmentation.
  • Consequence: Larger initial clone size (~600 files); requires careful .pro file organization to avoid build order issues; scaling beyond 150 projects may cause build slowdown.

• Custom widget implementation (QPainter) rather than QML/declarative UI

  • Why: More explicit control over rendering; easier for C++ developers to understand; minimal runtime overhead for simple controls.
  • Consequence: More verbose code per widget; harder to achieve complex animations; not ideal for rapid UI iteration or designer-driven workflows.

• Qt4/5/6 version compatibility across all projects

  • Why: Maximizes utility lifespan; educational value spans 15+ years of Qt evolution; reaches users on legacy systems.
  • Consequence: Cannot use modern C++17+ features; avoids Qt6-only APIs (QtQml, QtHttpServer); conditional compilation via #ifdef QT_VERSION_CHECK adds complexity.

• Minimal documentation (code comments > separate docs)

  • Why: Aligns with author's learning philosophy ('code as documentation'); reduces maintenance burden.
  • Consequence: New contributors must reverse-engineer patterns from code; lacks architecture diagrams or design rationale; onboarding steeper for non-native Qt developers.

• Not a real-time monitoring system — individual widgets are stateless; data sources (CPU/memory) are mocked or user-provided.
• Not production-grade enterprise software — prioritizes educational clarity over robustness; minimal error handling.
• Not a UI framework — each widget is self-contained; no unified theming system or component library contracts.
• Not a replacement for Qt documentation — complements official Qt docs by example; assumes reader knows Qt basics.
• Does not include automated tests — quality validated manually; no CI/CD pipeline artifacts.
• Does not support mobile platforms (iOS/Android) — Qt Mobile modules not targeted; demos assume desktop/embedded Linux.

Qt version matrix: some projects auto-skip on unsupported versions (Qt 6 incompatibilities noted in .pro comments)—read .pro comment blocks before building to understand CONFIG conditions. Compressed archive extraction can corrupt files (author recommends git clone to avoid 'Excess closing brace' parse errors). Standalone demo execution assumes bin/ directory exists; build system creates it, but manual runs may need mkdir bin/. Resource files (.qrc) in demos with images (devicebutton has 50+ icon PNGs) must be compiled in; qmake handles this automatically if .pro includes them. WeChat (feiyangqingyun) is primary support channel—no formal GitHub Issues section; bugs may not be tracked publicly.

• Greedysky/GreedyMusic — Another personal Qt education repo by same ecosystem; demonstrates custom UI themes and controls for music player—similar pedagogical goal and aesthetic.
• xclient-ll/qmlcomponents — QML-based custom widgets library; Qt ecosystem alternative for building reusable controls, complements QWidgetDemo's C++/QPainter approach.
• QtExamples/QtExamples — Official Qt 5 widget examples; canonical reference material—QWidgetDemo extends and improves on patterns found here.
• feiyangqingyun/qtkaifajingyan — Companion repo by same author (referenced in README) containing Qt development experience notes and advanced patterns—direct supplement to this demo collection.
• barry-ran/QtSwissArmyKnife — Qt-based multi-protocol debugging tool suite (serial, network, modbus); overlaps with QWidgetDemo's tool/ folder (comtool, nettool) and targets same embedded developer audience.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create a unified CMake build system alongside Qt .pro files

The repo has 100+ independent projects each with their own .pro files (e.g., control/battery/battery.pro, control/cpumemorylabel/cpumemorylabel.pro). Many developers now prefer CMake for better cross-platform support and IDE integration. Creating a root CMakeLists.txt and per-project CMakeLists.txt files would make the repo more accessible to modern Qt6 users and CI/CD pipelines without removing existing qmake support.

• [ ] Create root CMakeLists.txt that discovers and configures all subdirectories in control/
• [ ] Add CMakeLists.txt to at least 5 representative projects (battery, cpumemorylabel, devicebutton, lightbutton, navbutton) to establish the pattern
• [ ] Document in README.md how to build with CMake (e.g., 'mkdir build && cd build && cmake .. && cmake --build .')
• [ ] Test builds on Windows/Linux/macOS with Qt5 and Qt6 to verify compatibility

Add GitHub Actions CI workflow to validate all 100+ projects build correctly

With 100+ independent demo projects across control/, the repo lacks automated testing to ensure no build regressions when code is merged. Currently there's no .github/workflows/ directory. A CI pipeline would catch compilation failures on Qt4/5/6 across platforms before merged, which is critical for a teaching-focused repo where newcomers rely on working examples.

• [ ] Create .github/workflows/build.yml that matrix-tests on Ubuntu/Windows/macOS with Qt5.15 and Qt6.x
• [ ] Use official Qt GitHub Action (e.g., jurplel/install-qt-action) to install dependencies
• [ ] Configure workflow to attempt building all .pro files in control/ subdirectories sequentially or in parallel
• [ ] Add workflow badge to README.md so contributors see build status at a glance

Create a centralized resource (.qrc) file registry and auto-generation guide

The file structure shows individual projects have scattered image assets (e.g., control/devicebutton/image/ contains 36+ device button PNG files). There's no documentation on how resource files are organized or generated, making it hard for beginners to understand asset management patterns. Creating a guide with example .qrc templates and a script to auto-generate resource files would lower the barrier for newcomers extending these demos.

• [ ] Audit existing projects to document current .qrc file patterns (check if devicebutton, battery, etc. have .qrc files or load assets dynamically)
• [ ] Create docs/RESOURCE_MANAGEMENT.md explaining Qt resource file best practices with examples from the repo
• [ ] Add a sample python/shell script (scripts/generate_qrc.py or similar) that auto-generates .qrc files from image directories with user-provided patterns
• [ ] Update 2-3 projects to demonstrate the recommended asset structure and document in their README files

• Add unit tests for widget rendering: Create test/.pro with QTest framework checking paintEvent output for battery.cpp, navbutton.cpp (currently no formal test suite exists).
• Document API for each widget: Write doxygen comments for public methods in control/*/control.h files; generate HTML docs and add to repo (currently only inline comments, no API reference).
• Port a missing tool to Qt 6: identify a tool in tool/ marked unsupported in its .pro and refactor platform-specific code (e.g., QSerialPort API changes) to support Qt 6.

This is an educational Qt widget demonstration project with relatively low security risk, primarily because it is a demo/educational codebase with no backend services, databases, or network communication. However, there are operational security concerns: personal contact information and file sharing links are publicly exposed in the README, which could facilitate social engineering or unauthorized access to distributed binaries. The project lacks formal security documentation and vulnerability disclosure processes. No critical code injection vulnerabilities were identified in the visible structure, but custom widget implementations should undergo security review to ensure proper input validation. The codebase would benefit from a formal security policy and hardening of information disclosure practices.

• Medium · Hardcoded Contact Information and External Links — README.md (lines 4-5). The README contains hardcoded QQ numbers, WeChat IDs, Taobao shop links, and personal contact information. This exposes personal identifiers and could be used for social engineering or impersonation attacks. Fix: Remove or obfuscate personal contact information from public repositories. Use a dedicated contact form or official website instead.
• Medium · Unencrypted File Sharing Links — README.md (lines 7-8). The README contains direct Baidu Cloud sharing links with extraction codes for distributing binaries and resources. These links are publicly accessible and could be compromised or intercepted. Fix: Use secure, authenticated file distribution mechanisms. Implement access controls and consider hosting files on official, secured infrastructure.
• Low · Missing Security Policy Documentation — Repository root. No SECURITY.md file or security policy is present in the repository. There is no documented process for reporting security vulnerabilities. Fix: Create a SECURITY.md file with instructions for reporting security vulnerabilities responsibly, following standard disclosure practices.
• Low · No License Enforcement Mechanism — README.md and LICENSE. While a LICENSE file exists, the README explicitly states 'code can be freely distributed' with no enforcement mechanism. This could lead to misuse without accountability. Fix: Clarify licensing terms explicitly. Consider using license headers in source files and implementing version control checks.
• Low · Missing Input Validation Documentation — Control components (battery, devicebutton, imageswitch, etc.). As a Qt widget demo project with multiple custom controls (battery, buttons, tables, etc.), there is no visible documentation about input validation or secure coding practices for custom widgets. Fix: Add documentation on secure widget usage, input validation requirements, and potential attack vectors. Implement input sanitization in custom controls.
• Low · No Dependencies Security Scanning — .pro project files (implicit Qt dependencies). Qt framework and its dependencies are not explicitly listed in a package manifest. There is no evidence of vulnerability scanning or dependency management strategy. Fix: Maintain an explicit dependency inventory. Use automated tools to scan for known vulnerabilities in Qt and other libraries. Document minimum versions required.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.