Electron + React rewrite of Quantum Brush#40
Electron + React rewrite of Quantum Brush#40Akri-A wants to merge 3 commits intomoth-quantum:sourcefrom
Conversation
Complete modernization of the Quantum Brush desktop app: - Single-window Electron + React + TypeScript architecture - Fabric.js canvas with brush, eraser, dot, and select tools - All 10 quantum effects preserved and integrated via IPC - Tailwind CSS dark glassmorphism design system - Import/export for PNG, JPEG, SVG, and .qbrush project files - Cross-platform packaging (macOS, Windows, Linux)
|
Hey everyone, I've seen some discussion around different approaches to this issue, so I want to lay out more about the reasoning behind my submission and why I believe the decisions I made are the right ones for this project. Addressing every requirement in the issueIssue #32 has four scored requirements. I wrote a full ISSUE_32_FULFILLMENT.md mapping each one to the actual code so reviewers can trace exactly where every point lands. Window arrangement & UI/UX workflow (10 pts): The original app had three separate floating windows. My rewrite puts everything into a single responsive Electron window: left sidebar for tools, center canvas that flexes to fill available space, right panel for effect controls, and a collapsible bottom drawer for stroke history. Keyboard shortcuts for every major action (V/B/E/D for tools, Ctrl+Z/Y, Ctrl+S, Space+drag to pan). It's a proper creative tool layout, not just a reskin. JSON communication system (10 pts): Full structured IPC pipeline going from React through contextBridge to the Electron main process and then to a Python subprocess, with typed instruction JSONs, PNG diff masks for output, and per-stroke SVG archival. Python runs as an async subprocess with a 3-minute timeout, so the UI stays completely responsive even during heavy quantum computations. New design language (20 pts): I shipped a complete design spec document ( Full desktop application (60 pts): This is the bulk of the issue, and where I put the most work. All 10 quantum brushes working, a custom Why Electron is the right choice hereI've seen pywebview suggested as a lighter alternative, and I get the appeal on paper. In practice, though, Electron is the better fit for a creative desktop application, and here's why. Consistent rendering across platforms. Electron bundles Chromium, so the app looks and behaves identically on Windows, macOS, and Linux. pywebview relies on the OS-native web engine: WebView2 on Windows, WebKit on macOS, GTK WebKit on Linux. That's three different rendering engines with their own CSS quirks and JS API differences. For a creative application where the UI is the product, you really don't want to be chasing platform-specific rendering bugs. Ecosystem and maintainability. Electron powers VS Code, Slack, Discord, Figma's desktop app. It has a massive community, excellent docs, and a predictable release cycle. When someone inherits this codebase down the line, there's a wealth of resources to lean on. Smaller frameworks simply don't have that safety net. The binary size argument doesn't hold up. pywebview might start at ~72 MB vs Electron's ~150-200 MB, but that comparison ignores reality. This app needs Python plus Qiskit, Qiskit Aer, SciPy, NumPy, PennyLane, JAX, Pillow. Once you bundle all of that through PyInstaller, you're easily looking at 500MB+, and PyInstaller is notorious for breaking with complex scientific dependency trees. Electron's overhead becomes a rounding error. My approach keeps Python as a clean subprocess with no PyInstaller headaches, just "Direct" JS-to-Python calls sound nice until they block. pywebview's bridge is synchronous by default, meaning a Python call from JS freezes the UI until it returns. Quantum effect computations can take seconds or minutes. Unless you build careful workarounds, the app locks up during every effect execution. Running Python as an async subprocess avoids this entirely, and the user can keep drawing while effects process in the background. What else this submission bringsThis is not a quick reskin, but a ground-up rewrite with a lot of iteration. Full TypeScript across the frontend for type safety and easier contributor onboarding. Zustand for state management (minimal, fast, no boilerplate). Fabric.js 7 as the canvas engine, a battle-tested library with selection, grouping, serialization, and SVG export built in. Hot module replacement via Vite for instant feedback during development. Legacy code preserved in Bottom lineI built this to fulfill the exact requirements of Issue #32, point by point, with documentation to prove it. It uses a proven, industry-standard stack that anyone can pick up and maintain. It ships all the features a user actually needs to paint with quantum brushes, not just a foundation for how those features might work someday. Happy to answer any questions or walk through the codebase with the maintainers if that would help. |
…ots/brush unification - Replace conditional panel rendering with CSS-based collapse (transition + overflow-hidden) - Use ResizeObserver instead of window resize event for reliable canvas sizing - Add before/after comparison listeners (qb:compare-start/end) in CanvasArea - Store beforeCanvasJson and resultDataUrl in StrokeRecord for comparison support - Implement install-packages IPC handler with dynamic dependency aggregation - Expose installPackages via context bridge in preload - Unify dots as brush sub-mode with sidebar highlight for both tools - Add click-and-drag support for continuous dot placement - Update README with stroke manager docs, dots drag feature, and package install info
1 participant
Complete modernization of the Quantum Brush desktop app:
This is part of unitaryDESIGN. It fulfills issue #32