GL is only a drawing API. Then you need to handle fonts (layout, rendering), input and focus (including compose and input methods), actual window management, ...
Things quickly become quite a lot less trivial than it initially seemed, and then you end up needing an actual toolkit.
You can certainly pick a more minimal one than a browser, but any application now requires a non-trivial toolkit.
> Qt6 does include a JS engine, but hopefully it's a bit more isolated.
I wouldn't expect Qt and Gtk's JavaScript engines to be better isolated than Chrome. They're just more avoidable.
> GL is only a drawing API. Then you need to handle fonts (layout, rendering)
Exactly. It should suffice. Render text on a texture using FreeType or, if you feel fancy, using HarfBuzz.
> input and focus (including compose and input methods), actual window management,
No, not for a circular menu which is 100% mouse-driven. It's much closer to a game than to a desktop app. It should be about as complex in its functionality as dmenu, driven by config files. An optional nice GUI configurator for it could be a self-contained web app.
> They're just more avoidable.
Exactly: it's harder to access them from non-programmatic context, e.g. from a maliciously crafted menu item or .desktop file. Or so I hope at least.
Things quickly become quite a lot less trivial than it initially seemed, and then you end up needing an actual toolkit.
You can certainly pick a more minimal one than a browser, but any application now requires a non-trivial toolkit.
> Qt6 does include a JS engine, but hopefully it's a bit more isolated.
I wouldn't expect Qt and Gtk's JavaScript engines to be better isolated than Chrome. They're just more avoidable.