[HN Gopher] Advice for the next dozen Rust GUIs
___________________________________________________________________
Advice for the next dozen Rust GUIs
Author : raphlinus
Score : 43 points
Date : 2022-07-15 21:09 UTC (1 hours ago)
(HTM) web link (raphlinus.github.io)
(TXT) w3m dump (raphlinus.github.io)
| stephc_int13 wrote:
| I 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.
| zem wrote:
| 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.
| stephc_int13 wrote:
| 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.
| game-of-throws wrote:
| Maybe you know this, but he already released an MVP for a GUI
| library: https://github.com/linebender/druid
| stephc_int13 wrote:
| Not an MVP but an early demo, from my point of view.
| tayistay wrote:
| 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.
|
| [1] https://github.com/audulus/rui
| game-of-throws wrote:
| 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.
| mwcampbell wrote:
| I'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.
|
| [1]: https://github.com/AccessKit/accesskit
| billconan wrote:
| I 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.
| modeless wrote:
| Dear Imgui has an impressive implementation of detachable tabs.
| https://github.com/ocornut/imgui/wiki/Multi-Viewports
| billconan wrote:
| That was the reason I studied SDL2 in the first place.
|
| It's working on linux, but buggy on Mac.
| zachrip wrote:
| What are some of the difficulties?
| billconan wrote:
| 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.
| billconan wrote:
| 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.
| modeless wrote:
| 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.
| raphlinus wrote:
| 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.
| dmitriid wrote:
| This advice is applicable to anyone building cross-platform UI
| toolkits, not just to Rust.
| pornel wrote:
| The 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.
| seanalltogether wrote:
| I 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.
___________________________________________________________________
(page generated 2022-07-15 23:00 UTC)