windows-app-rs
vgtk
| windows-app-rs | vgtk | |
|---|---|---|
| 1 | 14 | |
| 212 | 1,038 | |
| - | - | |
| 10.0 | 0.0 | |
| over 1 year ago | about 2 years ago | |
| Rust | Rust | |
| - | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
windows-app-rs
-
Rust: State of GUI, December 2022 – KAS blog
It sure is abandoned: https://github.com/microsoft/windows-app-rs#this-repository-...
vgtk
-
Rust: State of GUI, December 2022 – KAS blog
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/
-
Code bloat has become astronomical
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
- Vgtk - A declarative desktop ui framework for rust built on gtk and gtk-rs
-
A declarative desktop UI framework for Rust built on GTK and GTK-rs
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.
-
Hacker News top posts: May 28, 2022
A declarative desktop UI framework for Rust built on GTK and GTK-rs\ (23 comments)
-
Newbie here. Just finished reading the book. What now?
Build your own To-do List Application in Rust: https://bodil.lol/vgtk/
What are some alternatives?
twitvault - Easily Archive and Search Your Twitter Data with our Syncable Desktop App
neon - Neon: Serverless Postgres. We separated storage and compute to offer autoscaling, branching, and bottomless storage.
wxRust2 - re-exploration Rust binding to wx
headway - Self-hostable maps stack, powered by OpenStreetMap.
Relm4 - Build truly native applications with ease!
orbtk - The Rust UI-Toolkit.
contrast_renderer - Contrast is a WebGPU based 2D render engine written in Rust
areweguiyet - A website built for the Rust community
windows-rs - Rust for Windows
piet - An abstraction for 2D graphics.
flo_draw - 2D rendering libraries for Rust and FlowBetween