Thoughts on Rust GUIs


#62

@rocallahan In a sense that list isn’t of different kinds of applications, but of different kinds of UI libraries, with the classification of applications being a mapping “the kind of application which needs the X kind of UI library”.

Could you say a bit more (you’ve mentioned a bit w.r.t. browsers and games) what the characteristics of the applications themselves are which lead to them having different requirements of their UI libraries?


#63

GUIs are a big and complicated topic for sure. I’m doing a musicplayer and debugger in Rust and both needs a GUI. I used “dear imgui” for quite a while but in the end had to drop it because it simply didn’t scale to my use-cases.

I looked around quite a bit for alternatives but in the end settled for Qt being the best one to use (regardless of language) but I had issues with all the current wrappers for Qt so I ended up doing my own which I develop over here https://github.com/emoon/Rute (more detailed info here)

I can see the appeal of doing a native implementation in Rust for a GUI but it’s very important to be aware that is an enormous task and there are lots of opinions on the direction to take.

While I certainty support an effort for an “official” Rust GUI I think it will be hard to get there.


#64

In a sense that list isn’t of different kinds of applications, but of different kinds of UI libraries, with the classification of applications being a mapping “the kind of application which needs the X kind of UI library”.

That’s fair. Let’s say I’ve classified applications by their requirements.

Could you say a bit more (you’ve mentioned a bit w.r.t. browsers and games) what the characteristics of the applications themselves are which lead to them having different requirements of their UI libraries?

I think applications in class 1 either only target one platform, or have enough resources to write custom UIs for each platform they target and deem it worth doing so to get the very best results. E.g. the applications OS vendors write for their own platforms.

Applications in class 2 are generally reasonably simple, or the complex parts can be factored out and handled some other way (e.g. writing per-platform UI in some places). They generally don’t require customizing UI components in deep ways (difficult to do portably). Lots of undemanding business applications in this category.

Applications in class 3 include browsers and other applications that need very precise control and customization of UI components. For example browsers need to implement CSS layout and theming, the DOM event model, the complex CSS rendering model, features like spellcheck, handle absurd numbers of form controls on a page without crashing, etc etc. A very long time ago all browser engines used actual native form widgets but they all transitioned to reimplementing everything because it was the only way to make things work (even browser engines like Webkit and IE that really only cared about one platform initially!). I guess applications also fit into this category if they want Write Once Run Anywhere and a broad feature set without doing a whole lot of work — by reusing an existing solution.

I think category 4 includes a lot of games because they tend to have limited UI needs; consistency with the underlying platform is not seen as an issue; performance is really important (and historically platform GUI toolkits have interacted poorly with high-performance graphics output); they don’t need to interface much with other applications in the platform; and the UI needs of games don’t generally evolve much over the maintenance lifespan of the game.


#66

I’ve been working on GUIs for 15 years and can’t corroborate with that. A visual designer mostly complicates things, IMO. UI components, just like other components, evolve constantly. You have to have 2 sets of components - new/existing GUI components you are working on in source form and compiled components that are installed in the IDE/visual designer, and you have to keep the latter up to date, so they reflect the state of components actually used by your app. You won’t see a preview of a custom component in your designer (only a placeholder at best, possibly a designer error) anyway. Creating custom components is a drag because of this, you have to compile them, uninstall the previous version of a component from your visual designer and install a new one. You have to have some description language for your GUI (extra thing to know, can’t benefit from static typing). Bug fixing older versions of the app is also a drag because you have to have a visual designer with older components installed, at the state they were when that older version of the app shipped; simply checking out the old code branch is not enough. You can’t really do the same things from the visual designer you can do from code, so it inevitably feels limited. Finally, somebody has to work on the GUI designer itself, this time can be better spent elsewhere. For these reasons, I much prefer environments with fast compilation speed, live reload and type-safe GUI DSLs in the same language your app is written to any form of GUI designers.


#67

Android might be great source of inspiration for new GUI framework. Recently added GUI components are amazing:

  • RecyclerView for complex and fast list layouts
  • ConstraintLayout for complex and flexible relative layouts
  • VectorDrawable for scalable SVG graphics
  • DataBinding to not mess around with update-refresh logic

It’s community GUI libraries also great:

Google recomendations for Android apps are very useful, clean and comprehensive. There might be something like that, especially for design.

Also important lessons might be learned from Android:

  • Don’t use weird DSL for GUI framework
  • Visual editors are buggy, complex and heavyweight
  • There is no need in any front-end scripting language
  • Theming should be done properly

#68

Yes, and given modern HW, base it on HW Rendering GL/Vulkan etc.