maliang draws every widget on a tkinter canvas

Everything is painted, which is the whole design

maliang is described as a lightweight UI framework based on tkinter with all UI drawn in Canvas, and that single decision explains most of what the framework is and is not. In tkinter, the standard widgets are drawn by the platform's own toolkit, so a button on Windows does not look like a button on macOS, and matching a design across operating systems means fighting three native style engines. Drawing every widget on a Canvas moves that work into the framework, where one drawing routine can serve every platform. The trade is that the platform's built-in behaviours go with it: focus handling, keyboard navigation, screen reader support and the small interaction details that native controls give you for free are things the framework has to supply itself. For an application whose interface is mostly display with light interaction, that is a good bargain, and for a form-heavy tool it usually is not.

A small core with two optional groups

The package metadata shows a deliberately thin dependency profile. The only required dependency is typing-extensions, and the framework targets Python 3.11 or newer, which is a modern floor that tells you the project is not maintaining compatibility with older interpreters. Everything else is optional and split into two groups. The `opt` group handles platform appearance, with darkdetect for detecting the system theme, pywinstyles and hPyT for Windows, win32material for Windows, and Pillow for images. The `ext` group carries the feature extensions, with maliang-mpl for plotting, maliang-media for media, maliang-three for 3D and maliang-table for tables. The `opt` group has platform markers, so a macOS install pulls the darkdetect variant with the macOS listener and a Windows install pulls the Windows-specific packages, while the Pillow dependency is unconditional because images are not optional in a drawing model.

The typing is part of the pitch, not an afterthought

The keyword list and the classifiers describe what the project wants to be: typed, themed, modern-ui, ui-design, cross-platform, widget, custom and gui. The `Typing :: Typed` classifier is a formal commitment, and the `typing-extensions` runtime dependency exists to support it, which is what lets the framework use modern typing constructs while still running on 3.11. It also has a CITATION.cff file in the repository root, which is the marker of a project that expects to be cited in academic work rather than only used in production scripts. The documentation is built with mkdocs, the source lives under `src/` with the tests under `tests/`, and the repository carries a SECURITY.md and a CODE_OF_CONDUCT.md alongside the usual GitHub workflow configuration.

Three translations, and a docs site separate from the code

The README is available in English, Simplified Chinese and Traditional Chinese, with the Chinese versions in separate files, `README.zh-Hans.md` and `README.zh-Hant.md`, and the project is maintained by a single author, Xiaokang2022, who is listed as both the author and the maintainer. The documentation has its own address separate from the package site, with the project homepage and documentation at different paths on the same GitHub Pages site, and the changelog is published as a page rather than only as the `CHANGELOG.md` file in the repository. That is the arrangement of a project that treats its documentation as a product in its own right, which is consistent with the framework's audience being people building interfaces rather than people using a command line tool.

The version line moved slowly and then quickly

The release history is worth reading for what it says about the project rather than about the software. The recent tags are 3.2.0 from 2026-10-06, 3.1.5 from 2025-09-27 and 3.1.4 from 2025-08-02. So there is a long stretch where the minor version moved in small steps, and then a jump to a new minor with a gap of about a year between 3.1.5 and 3.2.0, which usually means a breaking change to the widget API rather than a burst of bug fixes. The last push to the main branch was on 2026-10-06, the same day as the 3.2.0 tag, so the current work is at the tip of the release line. The project is MIT licensed, with the licence file at the root of the repository.

Where the canvas model will hurt

The limitations follow from the same decision that creates the appeal, and it is worth being concrete about them. A canvas-rendered control does not get the operating system's text selection, caret navigation or assistive technology support for free, so a form with many inputs will need more work than the same form built from native widgets. Scrolling a large canvas is also the framework's problem rather than the toolkit's, and a window with a lot of content is where the difference shows. And because the framework paints everything, any text that must be selectable, copyable or read aloud has to be handled explicitly. None of that is a defect, it is the trade, and the question for an adopter is whether the visual consistency across three platforms is worth more than the interaction quality of native controls on the one platform you actually deploy to.

Editorial conclusion

Adopt maliang if you need a desktop interface that looks the same on Windows, Linux and macOS and you would rather not fight each platform's native widget theming. Do not adopt it if you need native widgets, accessibility behaviours that come with real controls, or an interface that scales to thousands of interactive elements, since everything is drawn by the framework itself. Verify first that your Python is 3.11 or newer, that you install the optional group matching your platform so the theme matches the system, and that the canvas drawing model suits the size of the interface you have in mind.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Xiaokang2022/maliang on GitHub