[Refactoring] Improve UX/UI of the App with Code Implementation

[artreadcode]

Quantum Brush is a multi-window graphical software with OpenJDK + Processing (Java) + Python combination. Using a creative framework such as Proessing is useful here to improve Java's graphical interaction on the image(s) (Canvas). However, using Java's old-school GUI design and making a complicated backend system between Java and Python are not ideal for modern graphical software, especially nowadays good design language and good window organisation is key for various sizes of computer screen and for cross-platform.

For example, Quantum Brush now has three different windows. (Two for main, one for occasional.) The detail of UI components can be seen under here. You can see the complicated UI organisation here.

QuantumBrush/src/UIManager.java

Line 9 in 4ca31e5

public class UIManager {

Control Panel, Canvas and Stroke Manager. Ideally, in this case, Canvas and Control Panel should be sit witnin one big window which is responsive to user's computer screen, and Stroke Manager can be opened up separately or underneath the main interface, which would be still within the one big main window. However, because of a constraint from Processing (Java)'s void setup() + void loop() structure, it's difficult to combine the canvas area (where void loop() is constantly referencing) and the areas (Control Panel and Stroke Manager) which are governed by Java's SwingX library.

• (10 points) CODE: Improve the window arrangement of the current Quantum Brush app. Improve the scattered UI/UX into calm, dedicated workflow.

Currently, the communication between Python backend and Java happens through JSON document, which is not ideal for graphical execution. Thus, we were reviewing using .svg data to improve this pipeline, and it's up to you who brings this feature by .svg or by other solutions.

You can witness that the code is making a JSON document based on user parameters and a stroke which is created from the brush paths.

QuantumBrush/src/FileManager.java

Line 43 in 4ca31e5

public void saveStroke(

• (10 points) CODE: Make the JSON communication system of the current Quantum Brush app, convenient for interaction between Java logic and Python backend, such as using the .svg file system.

So far, Quantum Brush uses the simple, default Java's SwingX style design language, which is not ideal for modern desktop applications. Thus, we're thinking of improving the app's design system, aligns with the good communication from software to user and looks great on Windows, Mac and Linux. (Right now, it seems like the app is from early 2010s 🥲) Thus, contribution using Figma or Sketch, etc. and making a demo of the improved UI/UX using Prototyping tool on Figma or ProtoPie, etc.

• (20 points) NO CODE: Design the new design language of Quantum Brush, using different design tools and prototyping tools of your choice. Submission of both design files (screenshots) and screen recording of prototyping session is required.

And if you are a team of designers and coders, you are more than welcomed to make the fundamentals of newly-designed Quantum Brush app. While designers are working for the task above, developers can bring new design to the real life. Any technical stak is welcomed, but ideally we were thinking about using Electron + React, OR C/C++ with openFramework like other graphical softwares. However, it's up to your decision.

• (60 points) CHALLENGE: For the team of designers and coders! Design the new UI of Quantum Brush and bring it into life by making a desktop application with technical stack of your choice, ideally using modern framework such as Electron. Implementation of basic feature is needed, such as creating a new project, importing an image, draw lines and dots on the canvas and save it for execution of quantum brush!

All the source codes for the app can be found under the source branch, which is here.

[Akri-A]

@artreadcode, hi, I have created a PR for the proposed app. Please let me know if there is any feedback. 😄

[Gmin2]

Hey we can implement the bounty right ?

cc @artreadcode

[artreadcode]

Dear @Gmin2 , I didn't quite follow your enquiry, but you can apply for bounties while making a PR request underneath specific issues.

[artreadcode]

Dear @Akri-A ,

Based on unitaryDESIGN's AI Slop rule:

A message from unitaryDESIGN about AI Slop: "While we are open to collaboration with LLMs for unitaryDESIGN, please note that fully AI-generated PRs are not acceptable. It is up to the discretion of the individual maintainers whether or not LLM-generated PRs are the right fit for their issues, and they have the right to reject those that appear fully AI-generated."

Thus, I would like you to indicate what scope of work you've done, with the brainstorming process of developing the new tech stack app, and how did you implement the Python + JSON backend to the new format.

Best,
Astryd

[Gmin2]

Dear @Gmin2 , I didn't quite follow your enquiry, but you can apply for bounties while making a PR request underneath specific issues.

Hey I was just asking that the issue is already resolved by the #40 or it is still open thanks

[artreadcode]

@Gmin2 It's still opened.

[Gmin2]

Hey @artreadcode , I have implemented in #41

Screencast.from.2026-02-19.23-09-06.mp4

[artreadcode]

Hello @Gmin2 ,

Based on unitaryDESIGN's AI Slop rule:

A message from unitaryDESIGN about AI Slop: "While we are open to collaboration with LLMs for unitaryDESIGN, please note that fully AI-generated PRs are not acceptable. It is up to the discretion of the individual maintainers whether or not LLM-generated PRs are the right fit for their issues, and they have the right to reject those that appear fully AI-generated."
Thus, I would like you to indicate what scope of work you've done, with the brainstorming process of developing the new tech stack app, and how did you implement the Python + JSON backend to the new format.

Best,
Astryd

[Gmin2]

I dont know why yu have told this an AI slop

The original app was the three separate windows - canvas, control panel, and stroke manager, all disconnected because of processing's void setup()/void draw() loop fighting with swing. I went through UIManager.java, FileManager.java, and StrokeManager.java to understand what each window actually does, and realised everything could fit into one window with floating
panels. for the backend, i dug into apply_effect.py and noticed process_effect() just takes a dict and file paths, it doesn't care where the data comes from so wrapping it in a fastapi server was a pretty natural swap for the old json-file-on-disk approach. i went with tauri over electron mainly because the rust side handles file i/o, image blending, and spawning the python server cleanly without the overhead of bundling chromium.

[artreadcode]

This is a mandatory question that I always ask to all participants except if it's a minor bug.I'll review this and get back to you.Sent from my iPhoneOn 19 Feb 2026, at 17:54, Mintu Gogoi ***@***.***> wrote:Gmin2 left a comment (moth-quantum/QuantumBrush#32) I dont know why yu have told this an AI slop The original app was the three separate windows - canvas, control panel, and stroke manager, all disconnected because of processing's void setup()/void draw() loop fighting with swing. I went through UIManager.java, FileManager.java, and StrokeManager.java to understand what each window actually does, and realised everything could fit into one window with floating panels. for the backend, i dug into apply_effect.py and noticed process_effect() just takes a dict and file paths, it doesn't care where the data comes from so wrapping it in a fastapi server was a pretty natural swap for the old json-file-on-disk approach. i went with tauri over electron mainly because the rust side handles file i/o, image blending, and spawning the python server cleanly without the overhead of bundling chromium. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>