# PyUIBuilder: a drag-and-drop GUI builder for Tkinter and CustomTkinter

> PyUIBuilder lets you place Python GUI widgets on a canvas and download the generated code. It supports Tkinter and CustomTkinter today, with Kivy and PySide still marked work in progress, and its licence splits free web use from a paid Electron app.

**PaulleDemon/PyUIBuilder** — Python GUI builder. GUI builder for Tkinter, CustomTkinter, Kivy(upcoming) and PySide [Project is being updated in private repo]

- Repository: https://github.com/PaulleDemon/PyUIBuilder
- Website: https://pyuibuilder.com/
- Stars: 2,620 · Forks: 219
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/paulledemon-pyuibuilder

## What PyUIBuilder solves, and the developer it targets

Tkinter's geometry managers are the part most people fight with. You write place(x=, y=, width=, height=) or grid() calls, run the script, look at the window, adjust numbers, and repeat. PyUIBuilder moves that loop into a visual canvas: the README describes the workflow as three steps, select a UI library, drag and drop widgets, then generate and download the code. The README's own summary is "Build python GUIs like Canva", which sets the expectation of a direct-manipulation editor rather than a code generator driven by a config file.

The target user is someone who already writes Python but does not want to hand-tune pixel coordinates, or someone teaching Tkinter who wants students to see the mapping between a widget on screen and the line of code that produces it. It is not aimed at developers who need a full application framework with state management, because the generated output is a layout script, not an app skeleton. The README's roadmap lists support for event handlers as upcoming, which tells you what the current output does not include: the buttons it generates are not wired to functions.

## The generated code is plain Tkinter you can read

The mechanism is straightforward once you look at the sample output in the README. The editor produces a single Python file with a comment header, imports, a root window, one block per widget, and a mainloop() call. Here is the shape of it, taken from the README's tkinter example:

```python
# This code is generated by PyUIbuilder: https://github.com/PaulleDemon/PyUIBuilder

import tkinter as tk

main = tk.Tk()
main.config(bg="#332f2f")
main.title("Main Window")

label = tk.Label(master=main, text="Sample text")
label.config(bg="#E4E2E2", fg="#000")
label.place(x=83, y=69, width=130, height=46)

main.mainloop()
```

Two things stand out. First, positioning is emitted as place() with absolute coordinates, so the layout is fixed rather than responsive unless you switch the layout manager in the editor. The README states the tool supports flex, grid and absolute positioning, so place() is a choice made per project, not a hard limit. Second, third-party widgets appear as real imports. The full README sample pulls in tktimepicker and tkintermapview, and the README notes that a requirements.txt is generated when needed. That is the useful part: the output is not a proprietary format you have to keep re-exporting, it is a script you can edit by hand and abandon the tool with.

The README also warns that "Tkinter is OS dependent, output may vary based on OS", which is a fair caveat for anyone previewing a layout on one platform and shipping to another.

## Running PyUIBuilder locally from the repository

The README points to https://pyuibuilder.com for trying the tool and to the docs page for getting started. If you want to run the editor itself, the repository is a React application built with webpack, and package.json pins Node to version 18 or higher.

```bash
npm install
npm start
```

The start script runs env-cmd against the development environment and serves the app through webpack, so you should end up with the editor on a local dev server rather than the hosted site. For a production bundle the repository defines a separate build script:

```bash
npm run build
```

There is also a documentation server, which is useful because the docs directory ships with the repository:

```bash
npm run docs:serve
```

A first real use is to build one small window and export it. Pick Tkinter as the framework, drag a label and a button onto the canvas, set their background and text, then use the generate and download step the README describes. Open the downloaded file, run it with python, and compare the window to the canvas. The gap you will notice first is the missing button callback, since event handlers are on the roadmap rather than in the current feature list.

## Where PyUIBuilder stops being the right tool

The framework list is the clearest limitation. Tkinter and CustomTkinter are checked; Kivy and PySide are both marked work in progress in the README, and PyQt or PySide support appears again in the roadmap section. If your project is committed to Qt, the editor cannot help you yet, and no amount of layout work in the canvas will produce the PySide file you need.

The second limitation is the maintenance arrangement. The README carries an important note stating that the project is now maintained in a private repository and is continuously updated there, and the funding section says premium features are added and maintained in private. The public repository's last push was on 2026-08-07. That does not mean the tool is abandoned, but it does mean the public commit history is not a reliable signal of what the hosted product does today, and an issue filed against the public repo may not map to the code you are using. Treat the hosted editor as the product and the repository as a partial mirror.

Third, the licence is not a standard open source licence. The repository metadata reports NOASSERTION, and the README splits rights by surface: a section for the web based editor, one for the Electron app under a hobbyist licence, and one for the Electron app under a commercial licence. Anyone who needs an OSI-approved licence to satisfy a procurement rule should read License.txt before assuming this qualifies.

## How it differs from hand-written Tkinter and from Qt Designer

The realistic alternative is not another Python GUI builder, it is writing the layout yourself. That is a real option and often the better one. A hand-written Tkinter file uses the same place() and grid() calls PyUIBuilder emits, so nothing about the output is inaccessible to you; the builder just saves the trial-and-error loop. If your interface is a handful of widgets, the loop is short and the tool adds a round trip through a browser and a download. If your interface is a form with twenty fields and a preview you keep re-checking, the canvas pays for itself.

The other comparison worth making is Qt Designer, which ships with Qt's Python bindings and produces .ui files that load at runtime through uic or QUiLoader. The difference in approach is where the layout lives. Qt Designer keeps it in a separate XML file that the application loads, so the interface and the logic stay in different files and the interface can be swapped without touching Python. PyUIBuilder generates Python source, so the layout becomes code you edit in place. That is simpler to read and simpler to diff, but it also means regenerating overwrites your edits unless you keep the generated file separate from the code that uses it. PyUIBuilder does not target Qt anyway, so for a Qt project the comparison is academic.

## Licence, funding and what upgrading costs you

PyUIBuilder is a solo project. The README states that Paul works on it alone, from design to coding to maintenance, and the funding section asks users to purchase a licence with a one-time payment for instant access to premium features for life, described as a limited-time offer. The README's licence table has three columns: Free, Premium Hobbyist per user, and Premium Commercial per user, with the commercial tier priced per seat.

The practical consequence is that the free tier and the paid tiers are not the same product surface. The README's note says premium features are maintained in private, so feature parity between what the public repository can build and what the hosted editor can build is not something the public files let you verify. If you are evaluating for a team, the questions to settle before paying are which surface the licence covers (the web editor, the Electron app, or both), whether the commercial per-user tier is required for internal tools, and what happens to your access if the project stops being updated. The README does not document a refund policy or a migration path, and the README does not document rollback for generated code either, because there is nothing to roll back: the output is a file you keep. This is not legal advice; read License.txt and the pricing page for the terms that bind you.

## What the roadmap does and does not promise

The README lists three upcoming items: support for event handlers, PyQt and PySide support, and a downloadable Electron app. All three are on a Notion roadmap page linked from the README, alongside a separate what's new page, which means release notes live outside the repository. Nothing in the public files gives dates for any of them, and the presence of an Electron licence tier in the README while the Electron app is still listed as upcoming is worth noting: the licensing structure is ahead of the shipped artifact.

For a build decision, the honest reading is that Tkinter and CustomTkinter are the supported path today, and everything else is a plan. If your choice between PyUIBuilder and writing Tkinter by hand depends on Kivy or PySide arriving, you are betting on a roadmap item with no public timeline. The framework-agnostic claim in the feature list is an architectural statement about how the generator is structured, not a statement about which frameworks currently produce working output.

## Conclusion

Adopt PyUIBuilder if you want a Tkinter or CustomTkinter layout drawn visually and exported as a .py file you then own and edit, and if you accept that the public repository is no longer where development happens. Skip it if you need PySide, PyQt or Kivy today, if you need event handler wiring in the generated output, or if a browser-hosted editor is unacceptable. Before committing, generate one screen with the widgets you actually use, check the emitted requirements.txt against your environment, and read the licence table for the Electron app if you intend to ship commercially.

## FAQ

### Is PyUIBuilder free?

There is a free tier and two paid per-user tiers, Premium Hobbyist and Premium Commercial, according to the licence table in the README. The README says a one-time payment gives instant access to all premium features for life, offered for a limited time.

### What is the best GUI maker for Python?

That depends on the framework you have chosen, and PyUIBuilder only covers part of the field: Tkinter and CustomTkinter are checked in its supported frameworks list, while Kivy and PySide are marked work in progress. If you need Qt, the README's roadmap lists PyQt and PySide support as upcoming with no date.

### Do people still use Tkinter?

PyUIBuilder's own framework list treats Tkinter as a first-class target, with CustomTkinter alongside it, and the README's sample output is a Tkinter script. The README does not give usage numbers.

### Which GUI is best for Python?

The README does not rank Python GUI libraries. It states which ones PyUIBuilder can generate code for, which today means Tkinter and CustomTkinter, with Kivy and PySide listed as work in progress.

## Sources

- [Issues](https://github.com/PaulleDemon/PyUIBuilder/issues)
- [PaulleDemon/PyUIBuilder on GitHub](https://github.com/PaulleDemon/PyUIBuilder)
- [Project website](https://pyuibuilder.com/)
- [README](https://github.com/PaulleDemon/PyUIBuilder/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/paulledemon-pyuibuilder