vgtk VS contrast_renderer

A pretty fun Rust GUI experienc is vgtk[0], which is doing a bunch of macro magic to give a "we're coding in React" vibe to GTK+. I don't really have a specific thing I want to code in a native GUI at the moment but if I did I think this would be the most tempting for me.

[0]: https://github.com/bodil/vgtk/

a stateful GUI markup language is react. it is not yet the case that react-like code works for desktop, though there are cool examples like vgtk https://github.com/bodil/vgtk

from what i gather from https://github.com/bodil/vgtk/issues/78, you're better off using realm

I'm always curious to see these projects, because I've been experimenting with a React renderer for the GJS bindings for a while. It's frustrating because GTK "feels like" it's so close to being able to support a vdom/declarative paradigm, but the devil is in the details.

The simple use-cases like "Window > Box > Label" are easy to get going. The more complex widgets like Stack/Grid/TreeView ... aren't.

This project seems to have the same issue: https://github.com/bodil/vgtk/issues/40

This is made more difficult now GTK4 has removed the Container base class, so there's no longer a unified interface for adding children (although it had caveats in the first place).

I totally get the GTK view that (presumably) specific widgets are more intuitive with specific add/remove APIs (like the grid - one doesn't really "appendChild" to a grid).

It just feels like: if there was a consistent container API comparable to the web's appendChild approach, a vdom/declarative approach would require only a very light wrapper. Without it, I keep coming back to the idea of implementing wrapper widgets that expose that consistent API instead. And that's just not something I want to maintain - effectively duplicating each GTK widget for the purpose of making it fit into a tree model.

It's also a problem of trying to wrap richer functionality (pack_start and pack_end) into a simpler set (append only) of course.

So I don't know exactly what my point is :) Perhaps cautioning the reader that the simplicity of the approach comes with a catch.

A declarative desktop UI framework for Rust built on GTK and GTK-rs\ (23 comments)

Build your own To-do List Application in Rust: https://bodil.lol/vgtk/

This is true, but there is a lot more to the story. For one, WebGPU does not (yet) support mesh shaders, though it may later as an extension. For two, consider a glyph such as "o" that has two contours. Real triangulation generates a mesh that only generates triangles between the outer and inner contours, and mesh shaders aren't good at that. There are techniques (cover and stencil) that draw twice, incrementing and decrementing a winding number stored in the stencil buffer (see contrast renderer[1] for a clean modern implementation), but it does require nontrivial tracking on the CPU side, and can result in lots of draw calls to switch between the cover and stencil stages unless sophisticated batching is done.

Compute shaders avoid all these problems and work on WebGPU 1.0 today.

[1]: https://github.com/Lichtso/contrast_renderer

Thanks!

You can also checkout the "feature/ui" branch in GIT [1] to get the UI framework prototype.

[1]: https://github.com/Lichtso/contrast_renderer/tree/feature/ui