Show HN: Native Tcl/Tk Wayland and Android Port | Hacker News Reader

Show HN: Native Tcl/Tk Wayland and Android Port

github.com

2 pointswusspuss2 comments

Native Wayland for Tk was proposed years ago as a hard GSoC project ( https://wiki.tcl-lang.org/page/GSoC+Idea%3A+Tk+Backend+for+t... ) - and let's be honest, it's very hard for humans. Turns out AI cracks it in a few hours.

Claude was given the freedom to make its choices from top to bottom, including stack and architecture. It came up with a thin X11 emulation layer, the same approach Tk's macOS and Windows ports already take - except this one is shared by Wayland and Android thanks to their similarity. The human in the loop merely tested and sanity-checked the outcome to her unexpected satisfaction. Tkabber (a large, long-lived XMPP client) runs on the Wayland port unaltered, and on Android with one small fix.

Unlike AndroWish (an SDL-based Tcl/Tk distribution for Android), this is a backend inside Tk itself, shared with the Wayland port: Cairo/HarfBuzz drawing, with touch and the on-screen keyboard handled in generic Tk through new commands and events.

If you want to experience an anachronism, you can try the APK of the Tk demo with an added multitouch example ( https://github.com/pounceandmiss/tk-wayland/releases/ ), and full-on Tkabber on Android ( https://github.com/pounceandmiss/tkabber-demo/releases/ ).

Open articleView on HN

It's an interesting project, and if it had been around a year ago, I would have wanted to use this as the basis of the Tk Wayland port (minus the Android part). We started from scratch because there was a need and there was nothing, at all, in the pipeline. The Wayland-all-the-way-down design is the most impressive part - we chose GLFW as the primary interface to Wayland because writing a full Wayland back end seemed too large a task. However, Cairo is a very heavy external dependency that appears to have been chosen by Claude because it's the most widely used 2D library on Linux, not because it is the optimal one. Also, the strong dependency not just on X11's API but its actual code seems to me to be misguided. The official Wayland port will continue to evolve even if the X11 port becomes unmaintained or even removed from Tk if no distributions support X11 in the future. Finally, it seems clear that while Claude nailed the port on a large scale, he hasn't done much usability testing. On Mutter, this port's menu cascades don't work and the menus themselves have odd placement. Using the port to run TkDiff, tooltips flash and then disappear. These seem to reflect some issue with how xdg_popup is implemented under the hood. The official Wayland port has had hundreds of hours of actual user testing in the widget demo, complex Tk apps, and other tasks to help refine the implementation and the user experience, and also, to iterate on the design - we chose to implement menus and popups as wl_subsurfaces, and they work better than xdg_popup in our view. So while the Claude port has impressive benchmarks, it's a bit rough around the edges - not surprising, given that it hasn't had those months and months of actual human users poking around with the running Tk widgets. I will say this port has inspired us to improve the clipboard implementation (now fully native, not shelling out to wl-clipboard) and the IME implementation. So we've definitely learned a bit from this port and are using some of its ideas to make the official Wayland port better.

Note that this project is separate from the official Tk port to Wayland which is mentioned in the comment on the GSoC page by "kevin_walzer - 2026-07-13 01:39:44".

Reply on news.ycombinator.com