Ply - Blog

Conquering IME, Community Projects, and the Road to Ply 2.0

Unknown — Sun, 23 Aug 2026 00:00:00 +0000

It has been over 4 months since the Ply 1.1 release</a> in April.</p>

Life got busy in good ways: I went on my senior trip to Berlin, found a boyfriend, moved in with him, started my first job, finished Flowquill</a>, and went to university orientation camp. Between all that, Ply saw some heavy engineering work.</p>

🔗</a>Rewriting input methods</h2>
Back in April, someone opened an issue showing that typing Chinese characters ended up reversed on Windows.</p>
If you only type in English, input seems straightforward: hit a key, get a character code, draw a glyph. Yet for most of the world, text input relies on multi-stage composition. With Pinyin, Kana-to-Kanji, Hangul, dead keys, or mobile voice-to-text, keystrokes aren't put down immediately. Ply had no real concept of an Input Method Editor (IME).</p>
Over the past four months, I rewrote the OS-level input pipelines. On Windows, that meant dealing with Imm32 and Text Services Framework messages. Linux required supporting both legacy X11 XIM and Wayland `text-input-unstable-v3</code>. Android and iOS needed native virtual keyboard hooks and predictive text streams. On web, I built an invisible DOM bridge to sync canvas state. For macOS, I worked with a cloud Mac until 4 AM rewriting Cocoa input delegates.</p>`
`The final diff was +4,884 lines and -1,019 lines, our largest single feature update so far. Input across all six platforms now behaves properly whether you type in English, Chinese, Japanese, or use accent keys.</p>`
🔗</a>What people are building</h2> Seeing what developers build with Ply is easily one of the best parts of working on it.</p> 🔗</a>Emergency weather tracking (rustywx)</h3> @kerryhatcher</a> is building rustywx</strong></a>, a radar and storm-tracking tool for EMA first responders, volunteer firefighters, and storm chasers on field laptops.</p> This hit close to home recently when I had to evacuate due to a forest fire one kilometer away. Being back home safe, it means a lot to know Ply may be used for real emergencies.</p> 🔗</a>3D-printed PCB stencils (vcode)</h3> @pszsh</a> (Jess) created vcode</strong></a>, a tool for 3D printing solder paste stencils. Normal slicers leave messy retraction blobs on tiny surface-mount pads. vcode</code> uses Connected Fermat Spirals to generate continuous-line G-code. Jess built the interface in Ply and compiled it for both native desktop and WebAssembly.</p> 🔗</a>Music notation (Cadenzier)</h3> @twilit-jack</a> is working on Cadenzier</strong></a>, a music notation editor. They have been testing architecture patterns in Ply, finding ways to manage signal bubbling and nested layouts with minimal boilerplate.</p> 🔗</a>License</h2> The two games I built with Ply are now public on GitHub:</p> Stratum</a></strong>: The turn-based multiplayer strategy game that originally motivated Ply.</li> Fungal Economics</a></strong>: A real-time strategy project centered around mycelial growth and resource networks.</li> </ul> I used the new Ply Noncommercial License 1</a> so anyone can study the code, mod it, or run private servers, while keeping commercial forks off the table. If you want concrete examples of shaders, networking, or UI state in Ply, check out the repos.</p> 🔗</a>Next</h2> Ply 1.2 is coming shortly, and I will do a dedicated release post once it ships.</p> Looking further out, planning for Ply 2.0</strong> is underway. The goal is to switch to an independent rendering backend. Dropping upstream dependencies will let us add first-class 3D support, combining Spline-like visual tooling with Ply's immediate-mode ergonomics, 2D/3D compositing, and zero ECS overhead.</p> 🔗</a>Sponsorships</h2> I plan to keep developing Ply regardless, but balancing school, work, and a cross-platform engine takes time.</p> I opened GitHub Sponsorships</a></strong> and Kofi</a></strong>. If Ply is useful to you or your project, backing it helps me focus more on Ply's development.</p> 🔗</a>Getting started</h2> If you want to learn more about Ply, you can take a look at the interactive docs</a>, or as before you can drop by GitHub Discussions</a> to share what you are working on.</p>



Ply 1.1: Building Polished UIs in Rust
Unknown — Sun, 05 Apr 2026 00:00:00 +0000
When I released Ply 1.0, a months ago, the response was incredible. The project already hit 250 stars on GitHub. But we have been continuing to improve Ply.</p>
🔗</a>The async nightmare</h2>
Applications need to do background work. If you do this on the main thread, your game stutters and your app freezes. If you do it in the background in Rust, you usually end up drowning in mpsc</code> channels and wrapping everything in Arc<Mutex<T>></code>. Getting the result back to the UI thread is a chore.</p>
Ply 1.1 fixes this with the new jobs</code> module.</p>
jobs</span>::</span>spawn</span>(</span></span>
  "save_game"</span>,</span></span>
  ||</span> async move</span> {</span></span>
    Storage</span>::</span>new</span>(</span>"my_app"</span>)</span>.</span>await</span>?</span></span>
      .</span>save_string</span>(</span>"save.json"</span>,</span></span>
        serde_json</span>::</span>to_string</span>(</span>&</span>game_state</span>)</span>.</span>map_err</span>(</span>|</span>e</span>|</span> e</span>.</span>to_string</span>())</span>?</span></span>
      )</span>.</span>await</span></span>
  },</span></span>
  |</span>result</span>|</span> {</span></span>
    if let</span> Err</span>(</span>e</span>)</span> =</span> result</span> {</span></span>
      eprintln!</span>(</span>"Failed to save game: </span>{</span>e</span>}</span>"</span>);</span></span>
    }</span></span>
  },</span></span>
)</span>?</span>;</span></span>
</span>
if</span> jobs</span>::</span>is_running</span>(</span>"save_game"</span>) {</span></span>
  ui</span>.</span>text</span>(</span>"</span>{</span>wave|Saving...</span>}</span>"</span>,</span> |</span>t</span>|</span> t</span>.</span>color</span>(</span>0xAAAAAA</span>));</span></span>
}</span></span></code></pre>
You spawn a job. It runs in the background. When it finishes, the completion callback runs on the main layout thread automatically. No channels to wire up. No mutexes freezing your UI. Works on all platforms, even wasm.</p>
Paired with the new storage</code> feature for reading and writing files across all platforms, state management feels a lot more natural.</p>
🔗</a>Polishing UI</h2>
Creating a UI is easy. Making it feel good is hard. Ply 1.1 introduces a Lerp</code> trait across the engine as well as perceptually smooth color blending.</p>
let</span> c</span> =</span> Color</span>::</span>from_hex</span>(</span>0x1E1E1E</span>)</span>.</span>lerp_oklab</span>(</span>Color</span>::</span>from_hex</span>(</span>0x4CC9F0</span>),</span> t</span>);</span></span></code></pre>
Oklab interpolation keeps the perceived brightness consistent, which makes animations look professional.</p>
We also added a complete standard set of easing functions. From ease_out_cubic</code> to ease_in_out_bounce</code>, you no longer need to write your own math functions to make a button press feel snappy.</p>
🔗</a>Responsive layouts</h2>
Native layouts often feel rigid compared to the web. Ply's layout engine now supports wrapping.</p>
ui</span>.</span>element</span>()</span></span>
  .</span>layout</span>(</span>|</span>l</span>|</span> l</span>.</span>wrap</span>()</span>.</span>wrap_gap</span>(</span>8</span>))</span></span>
  .</span>children</span>(</span>|</span>ui</span>|</span> {</span></span>
    // Elements automatically flow to the next row</span></span>
  });</span></span></code></pre>
We also added contain</code> and cover</code> aspect ratios, plus weighted grow!</code> sizing. You can now tell an element to take up exactly twice as much remaining space as its sibling using grow!(weight: 2.0)</code>. Building a responsive grid now takes seconds instead of manual math.</p>
🔗</a>The little things</h2>
There is a lot more in this release. We added setting scroll positions, drag-select for text inputs, a customizable scrollbar. Check out the full changelog</a> for all the details as well as a migration guide.</p>
You can try the new features right now in the browser on the interactive docs</a>.</p>
Update your CLI to get started:</p>
cargo</span> install plyx</span></span></code></pre>
Go build something smooth.</p>
Feel free to present your project</a> or ask any questions</a> on GitHub</a>.</p>


Building apps in Rust shouldn't be this hard, so I made Ply.
Unknown — Sun, 01 Mar 2026 00:00:00 +0000
I wanted to build a game in Rust. A multiplayer board game with a server, a client, and a common crate that holds all the shared game logic. Clean architecture. One language. Full control.</p>
That's when I ran into a wall.</p>
🔗</a>Everything I tried fell short</h2>
Bevy</a> crams you into an ECS that turns simple things into thousands of lines of virtual database queries. Its UI system is macro-and-node-based with impl Bundle</code> and ..default()</code> scattered everywhere. Bevy's architecture wouldn't work with what I had spent weeks building for the server.</p>
Iced</a> looked promising until I saw the code. ..default()</code> everywhere. .into()</code> on every line. The nesting is unclear and everything reads backwards, where the top element ends up at the bottom of the code.</p>
egui</a> was better, but you're manually calling .add_space()</code> for gaps and allocating rects. For a simple UI it's fine. For a real app, it gets tiring fast.</p>
Slint</a> impressed me with its clean nesting, but it's a separate markup language. You can't cleanly integrate it into Rust or connect it to your existing systems. parent.width</code> references and in property <real></code> declarations don't belong in a Rust codebase.</p>
I also looked at non-Rust options. I'm an avid Unity developer including VR. I've had experiences with Unigine and opened Unreal once to get confused and irritated. They're all too clunky. They give you zero control. Making a server and Godot work together with a shared crate? Not happening. I also had a terrible previous experience with Tauri trying to make a scooter rental app.</p>
Eventually I found macroquad</a>. It said it would run anywhere, and it felt close to what I wanted, inspired by Love2D's simplicity. But after a few hours, it was clear: if I kept going like this, I wouldn't be done in years. Macroquad is a rendering library, not an app engine. No layout system, no text input, no UI structure at all.</p>
So I needed something on top of it.</p>
🔗</a>Clay, and hitting the wall</h2>
I'd heard about Clay</a> from YouTube, a C layout library. I used Rust bindings and paired it with macroquad. I called it Clayquad.</p>
At first, it was great. I could finally build my game at a reasonable speed. Then reality set in.</p>
Bugs appeared everywhere. Use-after-frees. Race conditions in the C bindings. No texture management. I was Box::leak</code>ing images every frame just to satisfy the borrow checker. The documentation was sparse, so everything took forever to figure out.</p>
Then I hit hard limits. I wanted shaders. Impossible. I wanted rotation, one of the three fundamental graphics operations, and Clay couldn't do it. Scrolling had to be implemented manually. Text input didn't exist (those are only on, what, 99% of interactive applications?). I couldn't even imagine cross-platform accessibility support.</p>
I had to build something better.</p>
🔗</a>Porting, rewriting, and rewriting again</h2>
I kept building on top of Clayquad. The renderer, a text styling system, vector graphics support. Features kept stacking up through the end of 2025, but the foundation was still C. And the syntax was getting uglier with every feature I added. .end()</code> calls everywhere, deep indentation for every nested element, declarations that were painful to read.</p>
I started analyzing every UI framework I could find: Iced, egui, Slint, Bevy, HTML/CSS, Qt/QML. Studying what each one got right and wrong. I knew what the API should look like before I touched any code.</p>
In February I focused on this project. I ported the layout engine to 100% Rust, stayed up until five in the morning getting it working. The next day I implemented the new API I'd been designing. Then came shaders, accessibility, the cli, networking... and this website.</p>
I settled on builder pattern + closures</strong>. Closures cure the .end()</code> problem. Builder methods are cleaner than specifying every property with ..Default::default()</code>. You can chain .shader()</code> calls, choose .degrees()</code> or .radians()</code>, and everything stays readable.</p>
One use ply_engine::prelude::*</code> gives you everything. We use Into<T></code> everywhere. When .background_color()</code> accepts Into<Color></code>, it takes hex integers, float tuples, or macroquad colors. When .image()</code> accepts Into<ImageSource></code>, it takes file paths, embedded bytes, textures, or vector graphics. No hex_to_macroquad_color!()</code> wrappers.</p>
Every second you don't spend looking up how to construct a FloatingElementBuilder</code> is a second saved.</p>
🔗</a>The philosophy</h2>
The core principle behind every decision in Ply: make it easier while giving you full control.</strong></p>
Why immediate-mode, rebuilding the UI every frame? Because it's actually faster than tracking mutations. No matter how complicated your UI is, the layout takes a fraction of a percent of total frame time, most goes to libnvidia or the GPU. You have to redraw every frame anyway. Love2D already proved this works. Immediate-mode gives you complete control over what gets rendered and when.</p>
Why a single prelude? Because no developer wants to manage imports. One import standardizes what you can do and eliminates useless boilerplate.</p>
Why managers (TEXTURE_MANAGER</code>, MATERIAL_MANAGER</code>, FONT_MANAGER</code>, NET_MANAGER</code>)? Because everything runs in a loop, and there are few good ways to persist state between iterations. Back in Clayquad, you had three options for images: always loaded, loaded every frame, or build your own caching system. Ply's managers handle all of that in the background. Tell the engine where your image is, it handles caching, eviction, and lifetime. The same pattern applies to materials, fonts, and network requests. All simplifying memory across frames so you never think about it.</p>
🔗</a>What 1.0 looks like</h2>
Ply 1.0 ships with everything I wished existed when I started:</p>

Layout engine</strong> with flexbox-like sizing, padding, gaps, alignment, scrolling, and floating elements</li>
Full text input</strong>: cursor, selection, undo/redo, multiline, password mode, all keyboard shortcuts</li>
Rich text styling</strong>: inline colors, wave, pulse, gradient, typewriter, shadow, per character</li>
GLSL shaders</strong> on any element, with built-in effects and a SPIR-V build pipeline</li>
Accessibility</strong> via AccessKit on desktop, JavaScript bridge on web</li>
Debug view</strong>: a Chrome DevTools-style inspector. No other Rust UI library has this</li>
HTTP + WebSocket</strong> networking that never blocks the UI</li>
TinyVG vector graphics</strong> with on-demand rasterization</li>
Rotation</strong>: both visual and shape-level</li>
Sound</strong> playback</li>
Cross-platform</strong>: Linux, macOS, Windows, Android, iOS, and web, all from one codebase</li>
</ul>
🔗</a>Interactive docs</h2>
Any engine is only as good as its documentation. An engine might have great features, but if it takes you two hours to figure them out, those features are just distractions.</p>
Nobody should need to read as much source code as I did to build something. Nobody should need to make as many pull requests as I did. Everything should be easy to use.</p>
So I built an interactive documentation</a>. Live code playgrounds where you can tweak values and see the result instantly. Every concept has an interactive example. The docs teach by doing, not by lecturing.</p>
🔗</a>Try it</h2>
cargo</span> install plyx</span></span>
plyx</span> init</span></span></code></pre>
Two commands to get an app with a font from Google Fonts, feature flags, and a project structure.</p>
Check out the examples</a>, there's a shader playground, a snake game, and a todo app. On the home page</a> you'll also find an interpreter so you can try some of ply's syntax live. Everything runs in the browser.</p>
Explore the interactive docs</a>, they'll show you interactive examples where you can tinker with the code right in the browser. The source is on GitHub</a>, licensed under Zero-Clause BSD</a>. Use it for anything, no attribution required.</p>
Go build something.</p>