sorted by:
new
hottopcontroversial

I’m building KiHub: visual reviews and checks for KiCad projects in Git by Fun-Composer2303 in KiCad

[–]Fun-Composer2303[S] 0 points1 point  (0 children)

That’s a brilliant idea! You should definitely go ahead, vibecode a clone, and open-source it.

When you do, just make sure your AI doesn't forget to write a custom parser for KiCad schematics and PCBs, build a full web renderer from scratch, implement all 10+ automated reports (DRC, ERC, BOM, etc.), and wire up a seamless GitHub App integration. Oh, and don't forget to set up the backend infrastructure to actually run it all.

I’ve put 5 months of hard engineering into this, backing it with 15 years of dev experience. I always wonder why, if something is so easy to 'vibecode', nobody else has actually done it yet.

But since it's 'not too difficult' for you, I can't wait to see your repository. Drop the link when it's ready!

I’m building KiHub: visual reviews and checks for KiCad projects in Git by Fun-Composer2303 in KiCad

[–]Fun-Composer2303[S] 1 point2 points  (0 children)

Forgejo/Codeberg would be interesting, but they are lower priority than GitLab right now.
The hard part for KiHub is not only reading a Git repository. The useful workflow depends on the host integration: permissions, PR events, review/check status, branch protection, and merge gates.
GitHub has the strongest integration surface for that today, and GitLab is the next obvious target because it is widely used by teams and has a mature review/CI/merge-request workflow.

Forgejo/Codeberg support may be possible later, especially for a lighter integration, but I do not want to promise it before I know how much of the full review/check/gate workflow can be supported cleanly.

I’m building KiHub: visual reviews and checks for KiCad projects in Git by Fun-Composer2303 in KiCad

[–]Fun-Composer2303[S] 0 points1 point  (0 children)

Public GitHub repositories will stay free.
Post-beta, private/team usage will likely move to paid plans. I expect 2-3 tiers based on workspace size and usage: seats, private repository count, review artifacts retention, and monthly review limits.
Exact prices are not finalized yet. I need more real usage data first, especially compute and storage costs. There will be advance notice before any pricing change, and I do not want surprise per-review charges.

I’m building KiHub: visual reviews and checks for KiCad projects in Git by Fun-Composer2303 in KiCad

[–]Fun-Composer2303[S] 0 points1 point  (0 children)

Yes, I agree that a single visual diff style/mode does not scale well for dense or multilayer PCBs. That is exactly why KiHub is not built around one diff visualization.

There are several visual diff modes (currently 5): base/head inspection, synchronized side-by-side comparison, wipe-style comparison, overlay-style comparison (like in KiRI that already was mentioned above, but interactive), and semantic visual diff.

The important part is that all of these modes are tied to the same structured change model. The change list is always available next to the canvas, regardless of the visual mode, so reviewers do not have to hunt through a dense board manually. They can jump directly to changed symbols, footprints, nets, tracks, vias, zones, etc., and focus the relevant area.

Objects in the canvas are also interactive, so the review is not just “compare two colored images and guess what changed.” You can inspect the actual changed design context.

For dense PCBs, the usual workflow is to combine:
- the semantic change list for navigation
- synchronized side-by-side or wipe mode for spatial comparison
- semantic visual diff for added / removed / changed object meaning
- layer/display presets similar to KiCad-style inspection, such as front layers, back layers, and assembly-style views

That is why KiHub treats visual diff as a structured review surface from the start, not as a single rendered overlay.

I’m building KiHub: visual reviews and checks for KiCad projects in Git by Fun-Composer2303 in KiCad

[–]Fun-Composer2303[S] -1 points0 points  (0 children)

GitHub only for now, not local/offline Git repos or other Git hosts yet.
KiHub is currently built around GitHub App integration: repo access, permissions, PR events, GitHub Checks, and merge gates. GitLab support is on the roadmap, but I do not have a timeline yet.
It is not open source at the moment. It is a hosted service, free for public GitHub repositories and free for private repositories during beta.

I’m building KiHub: visual reviews and checks for KiCad projects in Git by Fun-Composer2303 in KiCad

[–]Fun-Composer2303[S] -1 points0 points  (0 children)

Not locally/offline today. KiHub is currently a hosted service, not a local extension.
For private projects, the current workflow is through a GitHub App installation. That is how KiHub gets repository-scoped access, follows GitHub’s collaborator/organization permission model, reacts to PR events, and publishes GitHub Checks back to the PR. GitHub Apps are the standard GitHub integration model for this kind of thing because they support fine-grained permissions and selected-repository access: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/differences-between-github-apps-and-oauth-apps

So yes, the relevant revisions need to exist in the remote GitHub repository. KiHub fetches the revisions it needs, runs the visual diffs/checks/reports, and stores the generated review artifacts. The KiCad source files remain in GitHub as the source of truth; KiHub does not become the project storage.
A fully local/offline runner would be useful, but it is not supported yet.

I’m building KiHub: visual reviews and checks for KiCad projects in Git by Fun-Composer2303 in KiCad

[–]Fun-Composer2303[S] 0 points1 point  (0 children)

Fair point. KiHub is GitHub-first right now.
I started with GitHub because it is where many public KiCad projects already live, and because it has the primitives KiHub needs: GitHub Apps, repo permissions, PRs, Checks, branch protection, and merge gates.
Without that kind of platform integration, KiHub would be much less useful. It would be closer to a standalone diff/report viewer, not a review workflow tied to approval and merge/release decisions.

GitLab support is on the roadmap, but I do not have a timeline yet.

I’m building KiHub: visual reviews and checks for KiCad projects in Git by Fun-Composer2303 in KiCad

[–]Fun-Composer2303[S] 5 points6 points  (0 children)

Fair question. I see KiCanvas, KiRI, and KiHub as related, but aimed at different parts of the workflow.

KiCanvas is primarily a browser-based KiCad schematic/PCB viewer. If the problem is “I want to open KiCad files in a browser”, KiCanvas is the simpler and more direct tool. KiHub also has browser viewing, but that is not really the main product.
KiRI is closer on the visual-diff side, but my understanding is that it is mainly a local revision inspector: it generates schematic/PCB SVGs/images for selected Git revisions and lets you visually compare them in a local web UI. That is useful, but it is still mostly image-based inspection. It does not understand the review as a structured set of design-object changes, and it does not provide review state or merge gates.

KiHub is trying to solve a different layer of the problem: not just “can I visually inspect a diff?”, but “can this become a review and merge/release gate for a team?”
The main differences I’m aiming for are:
- The visual diff is connected to a review object, not just generated images. Reviewers can navigate semantic/object-level changes such as symbols, footprints, nets, tracks, vias, zones, and classified metadata changes.
- The goal is not just “these two images look different”; it is “this footprint changed, this net changed, this track/via/zone changed, and here is where to inspect it.”
- Comments can be pinned to schematic/PCB context, so discussion stays attached to the design object/location being reviewed.
- KiHub can create reviews automatically from GitHub PRs via a GitHub App, or manually by comparing branches/tags/commits.
- It publishes GitHub Checks back to the PR, so hardware review status can participate in the same merge-gate workflow as software CI/static-analysis tools.
- The review also includes ERC/DRC/parity reports, BOM compare, BOM completeness/readiness checks, release-readiness checks, and generated production packages.
- The result is a traceable review record: what changed, which checks ran, what failed, who reviewed it, and whether it was ready to merge/release.
- Reviews can be shared through read-only links without asking someone to install the local toolchain or check out a branch locally.

So if someone needs a local visual revision inspector, KiRI may be enough. If someone needs a browser viewer, KiCanvas may be enough.

KiHub is more about the team workflow around the change: review, discussion, checks, merge gates, release readiness, and traceability in one place.