WindInput: a Rust Chinese input method built around code tables

One Rust core with three platform frontends

WindInput is a lightweight, fast, customisable open source Chinese input method, and the repository is structured to make the core reusable. The table of components in the readme names four parts. The wind_input crate is Rust and holds the core service, which is the input engine, the dictionary, candidate management, UI rendering and cross platform IPC. The wind_tsf component is C++ and handles the Windows Text Services Framework interface and keyboard event capture. The wind_macos component is Swift and is the macOS IMKit input method client. The wind_linux component is C++ and is a Linux Fcitx5 addon, which the readme marks as a preview with its own readme covering the extra desktop settings and known limitations.

So the same engine does the actual Chinese text composition on all three platforms, and only the thin platform integration layer differs. That is the right shape for an input method, because the hard part is the engine and the dictionary, and the platform part is mostly about getting keystrokes in and drawing a candidate window out.

The feature list gives the input schemes. It is designed for Wubi and code table input schemes, supporting Wubi 86 and mixed Wubi with pinyin, and it also provides full pinyin and double pinyin. The design is scheme driven, meaning input behaviour is defined flexibly through scheme files. There is a graphical settings tool with visual configuration where changes take effect immediately, and light and dark themes that can follow the system setting. The implementation is Rust with low resource use and fast startup.

The supported platforms are Windows 10 and 11, macOS 12 and later, and Linux through Fcitx5 in preview.

Installing per platform and the signing situation

The download page at windinput.com/download provides the installers, and the readme describes what to expect on each platform.

On Windows 10 and 11 in 64 bit, there is an installer version or a portable version, and after installing you switch to WindInput with Win and Space. The Windows program files and installer packages are digitally signed, but SmartScreen needs download volume to build reputation, so a newly released version may still be blocked, and the readme says to follow the More info, Run anyway prompt.

On macOS 12 and later there is a universal .pkg package covering Apple Silicon and Intel, and after installing you add WindInput under System Settings, Keyboard, Text Input, Edit, then select it from the input menu.

On Linux, in preview, there is a .deb package for amd64 and arm64 targeting Ubuntu 22.04 and later and Debian derivatives, and it works as an Fcitx5 input method engine. You install with sudo apt install ./WindInput-*.deb and then add WindInput to the input method list in the Fcitx5 configuration, and the system input method framework has to be Fcitx5.

The macOS caveat is the one to know about. The macOS build has not been signed and notarised by Apple, so when Gatekeeper blocks it you have to allow it under System Settings, Privacy and Security. That is a rough edge for a distribution that otherwise looks polished, and it is worth checking on a fresh Mac before you commit to it.

The core builds alone, the packaging tools are optional

The readme is unusually clear about what lives in this repository and what does not, which is helpful if you want to build rather than download.

Four companion projects are needed for the released installers, and each is maintained in its own repository. The wind-installer project is the Windows installer and uninstaller, a manifest driven general purpose packager. The wind-portable project is the Windows portable, or green, edition launcher that runs in place without installation. The wind-ui-rust project is a cross platform lightweight GUI library that the installer, the portable edition and the settings program all build their interfaces on. The wind-setting project is the graphical settings program.

The important detail is that all of these are optional. When they are placed alongside this repository, the build scripts build them too, and when they are missing the scripts skip them, so the core input method can be built and run on its own. The macOS .pkg is packaged directly from this repository by scripts/mac/dev.sh and the Linux .deb by scripts/linux/package-deb.sh, so neither of those needs an extra repository. The Windows installer and portable launcher reach the GUI library through the windui crate published on crates.io, so checking out wind-ui-rust locally is not needed for them, while only wind-setting is a path dependency, with windui = { path = "../wind-ui-rust" }, so building the settings program does require the sibling checkout.

The build requirements per platform are Rust stable plus Visual Studio 2022 with C++ desktop development and CMake on Windows, running .\scripts\dev.ps1, Rust stable plus Xcode with Swift 5.9 or later on macOS, running scripts/mac/dev.sh, and scripts/dev.sh on Linux for cross compiling the Windows artifacts. The build scripts download third party dictionary data and generate the complete data directories, and the contribution guide holds the detail.

Where the dictionaries and the design references come from

The readme has a long acknowledgement section, and it is unusually precise about what was used as a reference and what was used as data, which matters for anyone thinking about the licence position.

The primary reference is the RIME Zhongzhouyun input method engine, librime, which was the main reference for the scheme and dictionary formats, for candidate ordering and for whole sentence decoding, with its Weasel frontend as the reference for Windows TSF integration semantics and its Squirrel frontend as the reference for the macOS IMKit architecture. The second reference is Fcitx5, libime, for pinyin decoding including incomplete pinyin and the long word penalty, and for the user word frequency model, with fcitx5-macos as a comparison for macOS packaging and input source registration details. The Wubi interaction habits and feature set come from Jidian Wubi, and the Wubi 86 code table data comes from its Rime port, rime-wubi86-jidian. The pinyin dictionary and language model data come from rime-frost, the character pronunciation data from pinyin-data, and the simplified and traditional conversion dictionary from OpenCC. The Windows implementation was guided by the Windows Classic Samples and the official TSF documentation.

The distinction the readme draws is that the above are independent works and the project used them as implementation references without copying source code, while the data source parts remain under their own licence terms, which are detailed in NOTICE.md.

The licence story has a wrinkle worth knowing. The source code of the project has been under the GNU General Public License version 3 or later since v0.127.0, and versions released before v0.127.0 remain under the MIT licence they were published under. Works distributed based on modifications of this project must also be released under GPL-3.0 with complete source code. The dictionary data is a separate matter, governed by the licences of the upstream data projects, and NOTICE.md carries the full statements.

The naming request and the branding convention

There is a section on the project name that is worth reading even if you never fork the project, because it explains a constraint that applies to any GPL project with a recognisable name.

The GPL grants the right to use, modify and distribute the source code, but it does not include the right to use the project name and logo. The readme asks that anyone who forks and publishes publicly should change the project name and the logo, and should state that the fork is unofficial so that users can tell who actually maintains the software.

The readme is careful to say that the project is not a registered trademark, and that this is a convention and a request rather than a legal term, with the details in a dedicated BRANDING.md document. That honesty is a good sign, and it is also the kind of thing that tells you the maintainer cares about the difference between what the licence compels and what the project asks.

For a user, none of this changes anything. It matters for a packager, a distributor or anyone who wants to ship the input method as part of a larger product, and it is the sort of constraint that is much easier to read before you build a business on top of it than afterwards.

Where WindInput is the wrong tool

Three cases argue against it. The first is a macOS user who wants a clean install. The package is not signed and not notarised, so Gatekeeper blocks it and you have to go into Privacy and Security to allow it, and on a managed Mac that is a request to your administrator rather than a settings change. The second case is a Linux user on anything other than Fcitx5. The Linux support is an Fcitx5 addon in preview, so an IBus user, a GNOME-only setup, or a distribution that does not ship Fcitx5 gets no input method at all, and the extra desktop configuration that KDE Plasma needs is documented separately in wind_linux/README.md because it is not part of the default path.

The third case is a user who wants a maintained, signed, notarised build with an integrated settings experience today, because the companion projects are separate repositories. The wind-setting program is a path dependency, so building it needs a sibling checkout, and the installer and portable launcher reach their GUI library through crates.io rather than a vendored copy. That arrangement keeps the core buildable on its own, which is a real virtue, but it also means that assembling the full product is a multi repository operation.

There is a functional point too. The whole design is centred on code table and scheme driven input, with full and double pinyin provided on top, and for a user who only wants pinyin the project is one of several reasonable options rather than an obvious choice. The differentiator is the scheme file, and if you have no interest in editing a scheme the extra machinery buys you nothing.

On the licensing side, the change from MIT to GPL-3.0-or-later at v0.127.0 is significant for anyone who planned to redistribute the input method inside a closed product, and the dictionary data carries its own separate terms regardless of the code licence. The contribution process also asks for a CLA on the first pull request, and the repository has a CLA.md, an AGENTS.md, a CLAUDE.md, a githooks directory and a scripts directory.

Editorial conclusion

WindInput suits a user who wants a locally configured Chinese input method, especially one built around Wubi or a custom code table, and who is willing to tune scheme files rather than accept a fixed behaviour. It does not suit a macOS user who expects a notarised build, because the macOS package is unsigned and Gatekeeper has to be told to allow it, and the Linux Fcitx5 path is a preview rather than a finished frontend. Before you install it, read the documentation site, and note that the licence changed to GPL-3.0-or-later from v0.127.0 while earlier versions were MIT, with the last push on 2026-10-15 and the newest release v0.126.0 from 2026-10-13.

Frequently asked questions

Official sources

1. huanfeng/WindInput on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases