pythonguis-examples: a working reference library of Python GUI code across ten toolkits

What pythonguis-examples actually is, and who it is for

This is not a library. Nothing here is meant to be imported into your project as a dependency. The README describes the repository as an open collaborative collection of UI demonstrations, tutorials and examples, and the top-level layout confirms that: one directory per toolkit (dearpygui, flet, kivy, nicegui, pyqt5, pyqt6, pyside2, pyside6, streamlit, tkinter) plus a tools directory. Inside each toolkit directory the examples are organised by type, and every example ends in a main Python file called main.py.

The audience is narrow and specific. You are the target reader if you already know Python and are choosing or learning a desktop GUI toolkit. The repository answers the question that documentation pages answer badly: what does a complete program in this toolkit look like, including the parts the tutorial skips. The README points people who cannot decide between toolkits at the Which Python GUI guide on the project site, which is the honest framing. The code here is evidence for that decision, not the decision itself.

The second audience is people who want a starting skeleton. The demos are complete applications rather than isolated widget snippets: a web browser, a notepad, a calculator, a word processor, a media player, a paint program, a Solitaire game, a currency converter, a weather app. If you want to see how a real application wires menus, file dialogs and state together in PyQt6, the demos folder is a faster route than assembling the pieces from API reference pages.

How the repository is organised across ten toolkits

The structure is deliberately flat and predictable, which is the main reason it stays readable as it grows. The path pattern is [library]/[type]/[folder-name], and the README states that new contributions should follow it. That means a PyQt6 demo lives under pyqt6/demos/<name>, and the parallel PySide6 version lives under pyside6/demos/<name>. The README lists the same set of demos twice, once per Qt binding, with the two links side by side.

That duplication is the most interesting design decision in the repository. PyQt6 and PySide6 are two bindings for the same Qt toolkit, and the demos are near-identical in structure, so publishing both versions makes the API differences visible by comparison rather than by prose. You can open the browser demo in both directories and see what changes. The README also flags which demos were built with QtDesigner, which matters because those examples include a .ui file and a different loading path from the hand-coded ones.

The other eight toolkit directories follow the same convention but without the paired-binding symmetry. Flet, Kivy, NiceGUI, Streamlit, DearPyGui and Tkinter each get a directory, and there is no claim in the README that coverage is equal. The README says PyQt6 and PySide6 have many examples and describes the rest as also available, which is a fair signal that the Qt directories are the deepest and the others are thinner.

Installing an example and running it

The README gives a two-step workflow. Change into the folder of the example you want, install that example's requirements, then run main.py. The requirements are per-example rather than repository-wide, which is the right call here: a Tkinter example needs nothing beyond the standard library, while a PyQt6 example needs the binding and sometimes requests.

Start by changing into the example directory. The README uses pip3 and python3 explicitly, so the commands below match that.

cd pyqt6/demos/browser
pip3 install -r requirements.txt

The README states that in most cases the only requirements are the GUI library and occasionally requests. After the install completes, run the entry point:

python3 main.py

The README says the application window should appear. There is no launcher, no project-wide virtual environment and no build step. If you want isolation, create the environment yourself before the install; the repository does not prescribe one, and the README does not document rollback or cleanup beyond removing the environment.

For the demos built with QtDesigner, the practical difference is that the widget tree lives in a .ui file next to main.py rather than in Python. The README marks which demos those are (the calculator, the notes app, the paint program, the unzip tool, the translator and the weather app), so you know before opening the folder whether to expect a .ui file.

The limitation: it is a collection, not a maintained dependency

The honest failure mode is version drift. There are no releases in the repository metadata, so there is no tag that tells you which commit was tested against which PyQt6 or Kivy version. Each example pins its own requirements.txt, and those pins were written when the example was added or last touched. The last push to the repository was on 2026-03-19, so recent work has happened, but a push is not a compatibility guarantee across ten toolkit directories.

In practice this means the first error you hit is likely to be an import or an API signature that moved. That is not a defect unique to this repository; it is the cost of publishing runnable code against fast-moving GUI libraries. But it does change how you should use the code. Treat every example as a starting point to port, not as a working baseline you can trust to run unchanged. If an example fails on install, the useful move is to read its requirements.txt, check what it pins against the current release of that binding, and adjust.

The second limitation is scope. The repository is examples, so it does not cover packaging, code signing, distribution or application updates. The README says nothing about turning a demo into a shippable binary. If your question is how to ship a PyQt6 app to users, this repository will not answer it, and the absence is not an oversight so much as the boundary of what an example collection is for.

How it compares with a framework like Toga or a widget toolkit's own examples

The closest point of comparison is not another example repository but a cross-platform framework such as Toga, which wraps native widgets behind a single Python API so one codebase targets multiple platforms. The approach here is the opposite. pythonguis-examples does not abstract anything. Each directory teaches you the toolkit directly, which means you learn PyQt6 by writing PyQt6, not by writing a portable layer that hides it. If you need one codebase across desktop and mobile, Toga or Kivy are the relevant choices, and the Kivy directory here will show you Kivy's own model rather than a wrapper over it.

The second comparison is against each toolkit's own shipped examples. Qt ships its own demo set, and Kivy, Flet and NiceGUI all publish examples. The difference is consistency of presentation. Here the same demo concepts (browser, notepad, calculator, paint) recur across toolkits, so you can compare how the same application shape is expressed in PyQt6 and in Flet without context switching between documentation styles. That parallel structure is the repository's real value, and it is something a single toolkit's examples cannot provide by definition.

Licence and the cost of keeping a fork in sync

The repository is MIT licensed, and the README states the examples can be freely re-used, re-mixed and tweaked. For copying code into your own project, MIT is permissive and requires only that the licence and copyright notice travel with substantial portions of the code. That is the general shape of the obligation, not legal advice; if you are redistributing a modified demo, read the LICENSE file at the repository root and handle attribution deliberately.

Upgrade cost is the part worth thinking about before you fork. Because there are no releases and no versioning, there is no upgrade path to follow. If you fork the repository to keep a set of examples working against current toolkit versions, you own that maintenance yourself. The practical alternative is to copy the one or two examples you need into your own project and leave the repository behind, which keeps your dependency surface small. Contributing back is explicitly welcomed: the README asks contributors to fork, add example code under [library]/[type]/[folder-name], and open a pull request.

Which Python GUI should you pick, and what this repository can tell you

The repository will not answer that question for you, and it does not pretend to. The README redirects to the Which Python GUI guide on the project site for the decision itself, and the code here is the evidence you gather afterwards. What the repository does give you is a way to test the decision cheaply: pick two toolkit directories, install the same demo in each, and read both main.py files side by side. The paired PyQt6 and PySide6 demos make that comparison almost free, since the application is the same and only the binding differs.

What it cannot tell you is which toolkit suits your constraints. Performance, packaging story, platform support and long-term maintenance are not covered. The README's own framing is instructional: it points newcomers at the PyQt6 tutorial or the PySide6 tutorial, and describes the repository as a place to learn by reading complete working applications. That is the right expectation to bring. Use it to learn a toolkit's idioms, then verify the rest against that toolkit's own documentation.

Editorial conclusion

Adopt it if you are learning a Python GUI toolkit and want complete, runnable programs to read and adapt, or if you need a reference for a specific widget pattern such as a tabbed browser or a QGraphicsScene card game. Do not adopt it if you need a supported library with a release cadence and an upgrade path, because it is an example collection with no releases and no versioning, and the last push was on 2026-03-19. Before copying anything, open the requirements.txt in that example's folder and read what it pins, since the repository does not document a single supported version matrix across the ten toolkit directories.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. pythonguis/pythonguis-examples on GitHub
5. README