Small comment: It's possible to stitch together UI/video/3D without dealing with the compositor, if you use child windows instead (or in wayland terms, a subsurface). On win32 at least, it's a much simpler approach.
Advice for the next dozen Rust GUIs
11–20 of 279 posts
Re: Advice for the next dozen Rust GUIs
#12I have no business related to Rust, but after reading a few articles from this author, I tend to think that his approach to GUI toolkit design is deeply flawed. He is undoubtedly highly knowledgeable about the subject, but this knowledge may be a curse in his case. A mix of second system syndrome and Architecture Astronaut, trying to satisfy too many constraints can be a deadlock. I think the sensible approach is sta…
i am just interested enough in new gui toolkits that i have read through a bunch of blogposts, articles, and github repo docs for a ton of emerging ones. my overall impression is that if a lot of these "architecture astronaut" concerns are not at least planned for up front, they will never be implemented, so i welcome the OP's thoroughness in documenting the various issues to be taken into account.
I don't think that GUI toolkits that are in use today were born in their final form, or that everything was planned from the start.
I think that unfortunate early design decisions can lead to dead-ends, or extremely painful evolution, of course, and knowledge can help, but paralysis is in my opinion an ever bigger issue.
Making the perfect GUI Toolkit starts by making one that is Good Enough for some use cases.
Re: Advice for the next dozen Rust GUIs
#13I have no business related to Rust, but after reading a few articles from this author, I tend to think that his approach to GUI toolkit design is deeply flawed. He is undoubtedly highly knowledgeable about the subject, but this knowledge may be a curse in his case. A mix of second system syndrome and Architecture Astronaut, trying to satisfy too many constraints can be a deadlock. I think the sensible approach is sta…
Maybe you know this, but he already released an MVP for a GUI library: https://github.com/linebender/druid
Re: Advice for the next dozen Rust GUIs
#14I attempted to implement my own windowing library after studying winit and SDL2. The missing feature I need is supporting detachable tabs (like what chrome and sublime text have). I think for productivity apps, this is very important. But implementing a windowing lib from scratch is not easy.
Dear Imgui has an impressive implementation of detachable tabs. https://github.com/ocornut/imgui/wiki/Multi-Viewports
Re: Advice for the next dozen Rust GUIs
#15I have no business related to Rust, but after reading a few articles from this author, I tend to think that his approach to GUI toolkit design is deeply flawed. He is undoubtedly highly knowledgeable about the subject, but this knowledge may be a curse in his case. A mix of second system syndrome and Architecture Astronaut, trying to satisfy too many constraints can be a deadlock. I think the sensible approach is sta…
A more scrappy approach is what I'm trying to do with my library, rui [1]. Just get something out there. Also, it's really in service of my (already released) app, as opposed to trying to be a successful open source project. If others happen to like it, great!
That said, I think Druid is a good Minimum Viable Product. I just needed GPU acceleration for my app, and wanted something closer to SwiftUI, which I'm used to.
Re: Advice for the next dozen Rust GUIs
#16I attempted to implement my own windowing library after studying winit and SDL2. The missing feature I need is supporting detachable tabs (like what chrome and sublime text have). I think for productivity apps, this is very important. But implementing a windowing lib from scratch is not easy.
Also, do you think if multi-channel signed distance field is a good approach for GUI text rendering? I understand, for games, it can support extreme zooming with small textures. But for GUI (for example a text editor), we only occasionally resize fonts. I looked at some of the open source projects (mostly terminal emulators), they simply rasterize fonts onto a texture map using CPU. I wonder if signed distance field…
The best GPU accelerated text rendering I know of is https://sluglibrary.com/. Not based on distance fields. Unfortunately not open source, though it is a one-man project. Maybe someday one of the big tech companies will pay him a whole ton of money to open source it.
Re: Advice for the next dozen Rust GUIs
#17The background for this is that most existing UI toolkits are a poor fit for Rust.
Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time.
Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references.
Rust prefers everything thread-safe, but many UI toolkits can't even be touched from a "non-main" thread.
Rust's object-oriented programming features are pretty shallow, and Rust doesn't have inheritance. That makes it awkward to model most toolkits that have deep hierarchies with a base View type and a dozen of Button subclasses.
So instead of retrofitting mutable single-threaded OOP to a functional multi-threaded language, there's a quest to find another approach for UIs. This change of approach has worked for games. Rust wasn't nice for "class Player extends Entity" design, but turned out to be a great fit the ECS pattern.
Re: Advice for the next dozen Rust GUIs
#18I have no business related to Rust, but after reading a few articles from this author, I tend to think that his approach to GUI toolkit design is deeply flawed. He is undoubtedly highly knowledgeable about the subject, but this knowledge may be a curse in his case. A mix of second system syndrome and Architecture Astronaut, trying to satisfy too many constraints can be a deadlock. I think the sensible approach is sta…
Maybe you know this, but he already released an MVP for a GUI library: https://github.com/linebender/druid
Not an MVP but an early demo, from my point of view.
Re: Advice for the next dozen Rust GUIs
#19I attempted to implement my own windowing library after studying winit and SDL2. The missing feature I need is supporting detachable tabs (like what chrome and sublime text have). I think for productivity apps, this is very important. But implementing a windowing lib from scratch is not easy.
Dear Imgui has an impressive implementation of detachable tabs. https://github.com/ocornut/imgui/wiki/Multi-Viewports
That was the reason I studied SDL2 in the first place.
It's working on linux (with x11), but buggy on Mac.
Re: Advice for the next dozen Rust GUIs
#20I haven't looked closely at the latest rust gui projects, but from what I remember most of them seem to be focused on code driven ui layouts, which I think is going to be a non-starter for anyone doing serious application work. View hierarchies and layout rules are too big and too complex to be maintainable via hand coding. Even a moderately sized app can have hundreds of custom views or components that need constant refactoring. You really need something like xml or json or whatever to build out that tree structure and easily visualize it.