Pygubu is the runtime half of a two-project Tkinter toolchain

The XML is the interface, and the library is the runtime

Installation is a single package install, and the current version has an interpreter floor:

pip install pygubu

The mechanism is stated in two sentences. Pygubu is a rapid application development tool for building user interfaces for Tkinter, and the interfaces you design are saved as XML files which, using the builder, can be loaded by applications dynamically as needed. That is the whole architecture: a declarative description of widgets that is interpreted at run time rather than compiled into constructor calls in your source. The practical benefit is separation. A layout change becomes an edit to a data file rather than a refactor of a window class, and a designer or a translator can change spacing and labels without reading Python. The cost is that the layout is now a second artefact that can drift from the code, because nothing in the description says which widget variable in Python corresponds to which element in the file, so a rename in one place leaves a dangling reference the loader will report at the moment the window is built. The project says it is inspired by Glade, which is the same idea in the C and Python world, and the readme is explicit about what that means for this project. It is worth knowing that the readme calls the tool quick and easy development, which is a claim about the workflow, not a performance claim, and that the file format is the interface between two projects you may or may not both be using.

A widget list that shows the gaps in Tkinter were worth filling

The readme lists the bundled widgets by name, and the list is more informative than a feature count. There is an accordion frame and a hideable frame, which are containers that are not in the standard library and that anyone who has built a settings panel has written badly. There is an auto-arrange frame, a scrolled frame, and a calendar frame, which is the widget people most often fake with a pile of buttons. There is an editable treeview and a filterable treeview, both of which are the standard answer to the question of how to show a spreadsheet-ish list in Tkinter, and neither exists in the standard library. There are two input widgets for choosing paths, one as an entry and one as a button, and two for choosing colours and fonts, which is where a designer tool earns its keep, because a raw colour value in a file is unreadable. There are two tooltip widgets, one of them built on the themed toolkit, and a set of dialog helpers. And there is a docking system with a frame, a pane, and a widget, which is the single most substantial item here, since a dockable panel arrangement is the kind of thing that takes a library rather than an example. Read the list as a map of what Tkinter does not give you, and you will understand both what this package adds and what a project that does not need any of it should skip.

Themes reimplemented without the library they are based on

The readme describes a set of themes based on a well-known themed widget toolkit but implemented only with Tkinter, and that parenthetical is the whole engineering story. A modern look in Tkinter normally comes from a themed widget library, which wraps the standard widgets, provides a theme engine, and often ships a design system. Reimplementing the same visual style on the standard library alone means the widgets are the stock ones, restyled. That has a real consequence: you get the appearance without the widget set, and you get it without the dependency. A Tkinter application that adopts these themes can keep its imports to the standard library plus this package, which is attractive for a script you want to distribute to people who will not install a themed toolkit, and for a frozen build. The cost is that a stock widget has a fixed set of options, so restyling is bounded by what the underlying widget exposes, and any theme feature that requires a custom widget class has to be built rather than themed. If you are migrating an existing application that already uses a themed toolkit with its own widgets, this route means giving those up. If you are starting fresh and want the look without the weight, it is a reasonable trade. The readme does not enumerate the themes or say which version of the style they follow, so the practical check is to render one and compare.

Plugins for eight external widget sets, each behind its own extra

Beyond the bundled widgets, the readme lists plugins for external widget sets, and the packaging turns each one into an optional extra with a matching name. There are eight: a widget set with subframe and meter widgets, a modern themed set, a calendar, a map view, a table, an embedded web view, a modern themes package, and a sheet widget. Each is an extra you install if you need it, and there is an all extra that installs every one of them. Two of the entries have their own constraints worth noting. The modern themed set is bounded at a minimum version and additionally requires a packaging library and an image library, so it is the heaviest of the extras and the only one that pulls in more than a single package. The others are single-package extras with no version constraint, which means you get whatever the resolver picks, and if an upstream library changes its API, this project's plugin is what breaks rather than the upstream. That is the maintenance model of a plugin system and it is fine as long as you know it: a broken external widget set is a bug in this repository, filed here, and fixed by editing a plugin rather than by upgrading. The all extra is a convenience for development, not a recommendation, and installing eight widget libraries to use one of them is a heavier application than most scripts need.

The designer is a separate project, and that is why the readme is short

Since version 0.10 the project was split into two main modules, and the readme is explicit about what each one is. The core is this repository, which loads and builds user interfaces defined in XML. The interface editor is a separate project that helps you create the XML definition graphically. That sentence explains the shape of everything in this readme. There is no description of how to start because the readme sends you to the designer's documentation to do that, twice. There is no documentation section with real content, because it points to the designer's page and wiki. And the history is a link to a changes file rather than a narrative. If you are evaluating this project, the useful question is not what this package does but whether you want the pair. Someone who already has an XML file, or who is willing to write one, needs only this. Someone who wants to draw a window needs both, and the two versions have to agree, since the designer writes the format this library reads. A related detail is in the packaging: there is a packaging-tool hook entry point pointing at a module in the library, which means applications frozen with that tool get the resource files and the loader bundled correctly. Small, and the sort of thing that saves an afternoon when a frozen build cannot find its own XML.

A long-running project with a broad interpreter range

The maintenance picture is good and the version scheme is worth reading. The package metadata reads version 0.42.1, and the readme says the split into core and designer happened at version 0.10, so this is a project that has been refining one design for a long time rather than exploring several. It is classified as beta, which for a library at that version is a long-standing state rather than a warning about recent churn. The interpreter range is broad and deliberate: the requirement is 3.9 or later, and the classifiers run from 3.9 through 3.14, which is a wider span than most packages claim and means the library is tested against the current interpreter as it is released. The single runtime dependency is a backport of package metadata used only on interpreters before 3.10, which is a very small dependency surface and means a base install pulls nothing but the standard library. The repository adds a pre-commit configuration, a source directory, a tests directory, a development directory, a design samples directory, a changes file, an authors file, and a shell script for running things locally, plus both a modern packaging file and a stub setup script for compatibility. The licence is MIT. What is absent is as informative as what is present: no GitHub releases are published, so the version in your environment came from the package index and the changes file is the changelog.

Editorial conclusion

Adopt pygubu if you build a Tkinter application and want the layout separated from the code, because an XML description you can edit without touching Python is a real separation and the widget list shows the author has filled in the gaps Tkinter itself leaves. Do not adopt it expecting a visual designer in this package, since the designer is a separate project and this repository is the runtime library, so you need both if you want to draw rather than write XML. Four things to verify. That you are on Python 3.9 or later, which the readme states as the requirement for the current version. Which external widget set you want, because each is a separate extra and the custom one pulls in a version floor plus an image library, so installing everything is not free. How themes are handled, since the readme says the bundled themes are based on another library but reimplemented with Tkinter alone, which means a design that looks identical elsewhere may not look identical here. And whether your application can tolerate loading a resource at run time, because a missing or moved XML file fails at the point of use rather than at import. The licence is MIT and the package metadata reads version 0.42.1, with the last push on 2026-09-06.

Frequently asked questions

Official sources

1. alejandroautalan/pygubu on GitHub
2. Issues
3. License: MIT
4. README