Advice for the next dozen Rust GUIs
raphlinus.github.io
Advice for the next dozen Rust GUIs
1–10 of 279 posts
Re: Advice for the next dozen Rust GUIs
#2I'm the main developer of the AccessKit [1] project mentioned in this post. AMA. To preemptively answer one expected question, I know the project has been inactive for a while; I'm back to work on it in earnest starting this month.
Re: Advice for the next dozen Rust GUIs
#3I 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.
Re: Advice for the next dozen Rust GUIs
#4This advice is applicable to anyone building cross-platform UI toolkits, not just to Rust.
Re: Advice for the next dozen Rust GUIs
#5I 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.
What are some of the difficulties?
Re: Advice for the next dozen Rust GUIs
#6I 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 is really necessary.
Re: Advice for the next dozen Rust GUIs
#7I 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…
I'm not a fan of distance fields for GUI text rendering. Their main advantage in games is super-easy integration into the rendering pipeline (they're basically just a texture and a simple shader), but the quality is not quite as good as standard font rendering. There are other issues, including fairly large texture RAM requirements for CJK fonts, and no easy way to do do variable fonts. My main work these days is piet-gpu, which is intended to do 2D graphics (including font rendering) "the right way." In the meantime, using existing platform glyph rendering capabilities makes sense and will certainly give the best visual match to platform text.
Re: Advice for the next dozen Rust GUIs
#8I 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.
What are some of the difficulties?
you mean what are some of the difficulties of implementing detachable tabs using existing libraries?
For example, they don't give you the correct mouse coordinates once your mouse cursor is outside a window. I heard this is impossible to do if the underlining system is wayland.
Re: Advice for the next dozen Rust GUIs
#9I 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 starting with a Minimum Viable Product, cutting some corners and consciously making tradeoffs. And if success comes, then try to organically grow from there.
Re: Advice for the next dozen Rust GUIs
#10I 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.