Hi all,
I’m interested to see how others are approaching GUI development with their own apps! The current SDK docs are based around using TouchGFX, which is the ST tool we use internally to create apps.
What I do personally when creating apps is drive TouchGFX with Claude for a first pass, and then go in and manually edit the TouchGFX files.
TouchGFX is possibly a little bit of a limitation currently. We’re thinking of providing an LVGL example.
Ultimately I’d love to get to a point where we can offer a browser-based LVGL tool, which could speed up app development significantly.
Very interested to get everyone else’s thoughts on GUI development and the LVGL idea.
I’m constrained by using linux, so heavy bias against TouchGFX from the start. I set up a Windows VM, installed and configured TouchGFX and launched it once and figured abandoned that entirely because it’s painful in that context, so I work around TouchGFX ~100%.
LVGL, from my extremely biased position, seems strictly better in almost every way that matters to me than TouchGFX.
Where I use TouchGFX is copying an existing example app to bootstrap things, I start with what’s there and then either the idea fizzles out and I give up or I prove out the idea and rebuild it from scratch.
I use AI heavily for apps. Predominantly Claude Code and a local LLM. I make all my apps write everything they possibly can to a sidecar file during development, then use that and take pictures/video as appropriate so the AI can close the loop as much as possible.
I primarily use embedded-graphics for graphics, with varying degrees of success. It means reinventing the wheel, drawing text moves from “trivial” to “a thing”, but now I have a library I can use. I’m thinking I’ll publish some crates in case anyone else is interested as it saves some bootstrapping. Things like fix(cmake): key the GUI merge on the GUI target, not on TouchGFX by tobymurray · Pull Request #283 · UNAWatch/una-sdk · GitHub (and I have another one that can follow if that’s accepted) make experimenting more challenging than it needs to be right now.
Something simple (e.g., a toggle on a single screen) is eminently doable to a quality that I think matches the TouchGFX options (unless fancy animations come in to play). I’ve never used LVGL beyond starting up some example code, but I’d immediately be more on board with LVGL as compared to TouchGFX (I’d probably still mess around with Rust though because it’s fun).
1 Like
My answer is a bit of an outlier because I can’t run TouchGFX at all - my machine is ARM64 (WSL2 on Windows on ARM), the vendored TouchGFX libraries are x86-64 only, and the framework core is binary objects. So the whole ARM build runs in an amd64 Docker container under QEMU. Slow, but it works, and six apps have gone to the store that way.
What that forced, and what I’d now do by choice: TouchGFX only for the generated skeleton and the text rows. Every face is drawn by plain header-only C++ that the watch build and a host build both compile. On the host it renders into a PNG quantised to the same four levels per channel the icon packer produces (ABGR2222), masked to the round glass, and I look at it before anything gets flashed. Those renders live in the repo next to the decisions they settled. It’s caught things no test would have - a stroke sitting a few pixels inside its rim, a moon lit on the wrong side when the palette inverts - and it means the design can be argued about from a picture rather than from a photo of my wrist.
I’m using Claude Code end to end, including the TouchGFX files. Toby’s sidecar-file idea is exactly how I close the loop too - my sensor app writes a report file to its own folder on the watch and I copy that off over USB, so the AI reads what the watch actually did rather than what I remember it doing. Photos for the rest.
On LVGL: that would be very much appreciated. TouchGFX isn’t just an authoring barrier for me, it’s the single reason I can’t build natively. An LVGL example would turn my emulated loop into a native one, and a browser-based tool would be better again. One request if it goes that way: model the panel’s colour depth in the tool. Four levels per channel is a real design constraint (eg: two of my icons needed redrawing because a colour that looked fine on the desktop landed on the same level as its neighbour) and a tool that shows you that up front would save everyone test rounds to the watch.
1 Like
Thanks @smokey_foss and @shatter_poetry . Ok, it definitely sounds like we need to unlock LVGL for you! We’re aiming to get 1.5 out with clock faces and utility menu updates, then we’ll look at building an LVGL example. Really appreciate the detailed replies!
1 Like
Hi @smokey_foss and @shatter_poetry . There’s some updates to the SDK in preview that you might like. You can now follow the tutorial using LVGL instead of TouchGFX. There’s also a complete LVGL version of the Running app.
Dive into the docs here: RunLVGL - Building a Watch App GUI with LVGL — UNA Watch SDK 1.0 documentation
This doesn’t require any kernel changes, so it will happily run on 1.4.0.
I’ve tried to make it cross platform (Windows/Linux/MacOS), but if you run into any problems let us know.
2 Likes