20 ms·

Advice for the next dozen Rust GUIs

345 points by raphlinus 4y ago

mwcampbell 4y ago
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 https://github.com/AccessKit/accesskit
- favorited 4y ago
  This is a really interesting project. Accessibility support is near and dear to my heart. The readme mentions a macOS adapter prototype, but I don't see that directory. Does it exist in a different branch? I'd love to check it out – I'm pretty experienced with the Mac's AX implementation, but have basically no experience with AX on Windows...
  - mwcampbell 4y ago
    Oh wow, the readme is even more out of date than I realized. I yanked the Mac adapter prototype from the main branch last year. You can find it if you dig through history. I'll bring it back and continue working on it later this year; it's already on my schedule of work to do this year.
- password4321 4y ago
  Do you have a Patreon/whatever setup, since "this is the way" per baby Yoda?
  - mwcampbell 4y ago
    Not yet. But Google is funding my work on AccessKit again this year. I'll write a blog post about that work later.
billconan 4y ago
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.
- zachrip 4y ago
  What are some of the difficulties?
  - billconan 4y ago
    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 4y ago
  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.
  - raphlinus 4y ago
    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 4y ago
This advice is applicable to anyone building cross-platform UI toolkits, not just to Rust.
stephc_int13 4y ago
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 4y ago
  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 4y ago
    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 4y ago
  Maybe you know this, but he already released an MVP for a GUI library: https://github.com/linebender/druid https://github.com/linebender/druid
  - stephc_int13 4y ago
    Not an MVP but an early demo, from my point of view.
game-of-throws 4y ago
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.
- layer8 4y ago
  The article mentioned scrolling. Do you get smooth scrolling with that approach, when the child window is conceptually embedded into a scrollable view? I guess you should, because the traditional Windows controls are technically all windows (HWND), but I wonder.
- raphlinus 4y ago
  I could probably have written this in a clearer way. Child windows like a proto-compositor in a way, just with more limitations. You can put video/3D/etc content in a child window, but there are serious tradeoffs. When it's in a scrolling container, either your scrolling implementation is built from child windows, or you're going to deal with less than perfect synchronization as you overlay a changing clip/translate for the embedded content with draws of the rest of your UI (this used to be a common problem in browsers). Modern compositor APIs have explicit transactions[1, 2] causing the various view changes to be applied at the same time. It's not that the problem can't be solved, it's that it's trickier than people imagine. And of course a Wayland subsurface is using the compositor. [1]: https://docs.microsoft.com/en-us/windows/win32/directcomp/basic-concepts#synchronization https://docs.microsoft.com/en-us/windows/win32/directcomp/ba... [2]: https://developer.apple.com/documentation/quartzcore/catransaction https://developer.apple.com/documentation/quartzcore/catrans...
- c-smile 4y ago
  I am participating now in such project - 3D CAD alike application: it renders 3D scene in Vulkan with Sciter rendering auxiliary UI on the same Vulkan surface. Sciter manages dockable widgets, property editors, scene tree logical representation, menus, etc. on top of 3D scene. Approach is explained here: https://sciter.com/sciter-and-directx/ https://sciter.com/sciter-and-directx/ You see there exactly 3D, video and GUI around.
pornel 4y ago
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.
- kelseyfrog 4y ago
  Is there an ECS-compatible ontology for UI components?
  - bowsamic 4y ago
    In the post the author says the first architecture for Druid was ECS but they gave it up
- jchw 4y ago
  The thing is, there do exist UI frameworks that prefer composition over inheritance and strictly tree shaped components where data only flows one way: they're all the rage on the web. And that's great, because they give plenty of useful insight into things that work and don't work when designing UI frameworks this way. To be fair, it's not exactly like nobody realized this. More than one Rust desktop UI framework is explicitly React inspired, and it's not like FRP-based UI was non-existent prior to being popularized in web frameworks. Still, all the same... I suspect the best answers for how to do good UI in Rust are not far away from this paradigm.
  - 4y ago
seanalltogether 4y ago
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.
- favorited 4y ago
  I think the industry at large is moving in the opposite direction, towards declarative layouts written in code. As an example, for decades, Apple's UI design tooling (Interface Builder) was serialized to XML, but SwiftUI uses a DSL so your interfaces are written in code. I haven't been a web developer professionally for a while, but I've dabbled in React, where you build UI components in JSX, which is an extension of JavaScript. I don't see why Rust couldn't be successful with a similar approach.
favorited 4y ago
> On macOS ... going forward, it’s likely that new capabilities and evolutions of the design language will be provided for the latter [SwiftUI] but not the former [AppKit]. I think this is vastly over-stating the technical churn of UI development on macOS. While we're definitely seeing new UI toolkits introduced that are Swift-only (like the new Charts.framework[0]), nearly every Mac app Apple ships is written using AppKit. For example, I just verified (`otool -l PATH_TO_APP_BINARY`) that Mail, App Store, Notes, Music, Xcode[1], and Photos all link against AppKit, and none link against SwiftUI (on macOS 12.4 21F79, which I'm running). There is, in my opinion, approximately zero chance that Apple either: (A) rewrites all of the UI in all of their apps, replacing AppKit with SwiftUI, in even the medium-term, or (B) starts treating AppKit apps as second-class citizens by introducing a new design language only available from SwiftUI. Yes, we're going to keep seeing cool new widgets and features which are only available from Swift. No, the platform's design language is not going change in a way that makes AppKit apps obsolete. [0]https://developer.apple.com/documentation/Charts https://developer.apple.com/documentation/Charts [1]I bet Xcode links SwiftUI somewhere for IDE integration, but I'm specifically referring to the UI implementation, parts of which have been in development since, like, NeXTSTEP and are certainly built using Objective-C & AppKit.
- jolux 4y ago
  Aren't App Store and Photos Mac Catalyst apps?
  - favorited 4y ago
    Nope! Both are fully native macOS apps, at least on the version of Monterey that I'm running. You can examine which frameworks a binary links by running `otool -l /System/Applications/Photos.app/Contents/MacOS/Photos`. Traditional macOS Cocoa apps will link AppKit, while Catalyst apps will link UIKit. For example, if you run that command with a Catalyst app (e.g., Messages or Maps), you'll see that those apps link against `/System/iOSSupport/System/Library/Frameworks/UIKit.framework/Versions/A/UIKit`, and AppKit is nowhere to be found.
    - 4y ago
rustqt6 4y ago
Fwiw, I've head a great time with rust qmetaobject for some (basic) GUIs. Qt is more polished than any non-concerted (or even concerted) effort is going to be in at least half a decade
riquito 4y ago
Raphlinus, great post as usual, thanks for sharing your knowledge, is always an interesting read. I'm loosely following the progress of slint ui (formerly SixtyFPS), anything interesting in their approach or does it strictly matches one of your examples?
- raphlinus 4y ago
  I don't follow slint as closely as maybe I should. I'm definitely happy there's a real product out there, and would be happy to work with them on common infrastructure, but we haven't had much interaction (yet).
hardwaresofton 4y ago
Bit of a hot take, but I basically expect that most new Rust GUI projects will be written in Tauri before long. It works on multiple platforms, and is flexible, and it's easier to find off the shelf pieces due to the web technology involved, and it's lighter than Electron. It's a no-brainer for me (and others, I think) if I'm starting a new GUI desktop project.
- tmpfs 4y ago
  I think you are right about this with the one huge problem from my point of view being the text rendering on Windows. This is of course a problem with the Webview implementation on Windows but it is so awful it makes me want to use something else instead. Note this is not a reflection on Tauri which I think is awesome but Microsoft really should fix it.
  - favorited 4y ago
    Is there something blocking Tauri from switching to WebView2 on Windows? It's based on Chromium, so I assume most of the legacy web view issues would be irrelevant. IIRC, WebView2 is supported going back to Windows 7...
    - nguyenkien 4y ago
      Tauri use webview2 on Windows
  - oldmanhorton 4y ago
    Tauri uses WebView2 on windows, I believe, which should have the same text rendering as the Windows 11 start menu and Edge itself. You may be thinking of older IE-based webviews, which were used even well after "old edge" webviews were introduced because "old edge" webviews weren't supported on windows 7 or 8.
- xvilka 4y ago
  Hopefully, not. From my personal experience, Electron and alike applications are slower, larger, and in general have less advanced UI than many Qt or GTK-based (or Windows UI) applications. Nothing can beat good old native GUI frameworks.
asiachick 4y ago
> Instead of trying to decide whether a GUI toolkit is native or not, I recommend asking a set of more precise questions: > > * Does text look like the platform native text? > > * To what extent does the app support preferences set at the system level? > > * What subset of expected text control functionality is provided? > > * Complex text rendering including BiDi > > * Support for keyboard layouts including “dead key” for alphabetic scripts > > * Keyboard shortcuts according to platform human interface guidelines > > * Input Method Editor > > * Color emoji rendering and use of platform emoji picker > > * Copy-paste (clipboard) > > * Drag and drop > > * Spelling and grammar correction > > * Accessibility (including reading the text aloud) > > If a toolkit does well on all these axes, then I don’t think it much matters it’s built with “native” technology; that’s basically internal details. That said, it’s also very hard to hit all these points if there is a huge stack of non-native abstractions in the way. This is it! Browsers handle all of this. It's a ton of work. Many many gui kits start with just ASCII and really don't realize how deep the rabbit hole is for making all of this work. And as always, if you haven't read them https://gankra.github.io/blah/text-hates-you/ https://gankra.github.io/blah/text-hates-you/ https://lord.io/text-editing-hates-you-too/ https://lord.io/text-editing-hates-you-too/
overgard 4y ago
I think the web really killed the idea of "native" widgets. I think the rise of web apps just got everyone used to the idea that controls are just going to look different everywhere. Even on macOS, practically every app I use has a very distinct look and set of widgets (vscode, photoshop, blender, spotify -- two of those are electron, but even the non-electron stuff doesn't look very much like a "mac" app anymore). And in windows, microsoft really killed it themselves by constantly updating their own apps with non-standard widgets that everyone else wanted to clone (I remember the longest time it seemed like the only new things of note in every new version of ms office was how the toolbars looked). I suppose it's not a terrible thing, but I do kinda miss the days of windows 2000 and classic macos where the platform had a (somewhat) uniform look and feel.
- wmf 4y ago
  I think it's more a desire for branded UI rather than Web apps. Adobe wants their UIs to be instantly identifiable as Adobe, Slack wants to be instantly identifiable as Slack, MS Office as you said, etc. Personally, I doubt this benefits users (do you really need to market to people who already bought your product?) but I'm sure the logic is compelling to decision makers and it's cheaper to "design once, run everywhere". It also makes sense to developers that their app should look the same across OSes even though that "consistency" doesn't affect the 99% of users who only use one OS.
  - Nadya 4y ago
    What's funny is that it pisses off a large number of those 1% of users who swap OSs frequently as well. So it isn't even for the benefit of that 1% either. When operating a Mac I expect Mac-specific behaviors. When operating a Windows PC I expect Windows-specific behaviors. I LOATHE programs that decide to do away with OS-isms that I am accustomed to and require me to learn how to "do things their way" because they wanted cross-OS consistency. Sometimes this means conforming everything to a single platform which is partially evil but just as often it means conforming to _none of them_ which is pure evil. But I understand this - as a web developer I've experienced pressure from Project Managers and the "decision makers" to make things consistent across browsers/devices even if doing so goes against how the users of said browsers/devices would expect things to operate - breaking user expectations and creating a worse UX for many users. I fight against it when I can but I'm not always successful.
CrimsonVoid 4y ago
I know this is going to be a controversial opinion considering how much everyone seems to love Rust, but does anyone else find Rust incredibly painful to work with, even for simple tasks? Like I'm no stranger to unmanaged languages, and to some extent I cut my teeth on C, but doing anything with Rust always feels like the most aggravating exercise in needless verbosity and the "Lombok problem" doesn't help either. (Funnily enough, both these reasons are why I don't like Java either). I don't want to sound too negative, Rust is a very promising language, but even seven(!) years later it still feels like a pre-alpha language.
- avgcorrection 4y ago
  Why would people be annoyed? Plenty of people have done the same thing in this thread. Except they stayed on the GUI topic. So maybe that’s why you included the sheepish intro sentence.
- cturtle 4y ago
  Yes I do find it painful. Because rust’s memory safety restricts the number of valid programs, it is (to me) more difficult to write code. That’s not a bad thing though! It’s just not a trade off I’m willing to make most of the time. If my project requires the memory safety that rust offers, I’ll choose rust. But most of the time I’ll pick something else to lower my mental load when coding.
- __david__ 4y ago
  I don't find that. I was quite familiar with C and C++ before learning Rust and I find the places where Rust requires explicitness are the places where C lets you glide by and inject hidden bugs into your code. When my Rust code finally compiles it has an extremely high percentage chance to _just work_, where when C compiles you still have another whole pass of "find all the segfaults lurking around".
- josephg 4y ago
  I learned rust a few years ago, and almost all the code I’ve written in the last 18 months has been rust. Rust makes you deal with all the pain of learning it up front. Does that pain ever go away? In my experience, it mostly does. I’m now significantly more productive in rust than C, and I feel much more pleased with the end result. I still find it takes a lot more effort to write rust than javascript though. Both more thinking per line, and it often takes more lines of code. The resulting software is faster and more correct, but it’s not a uniform win. I still reach for javascript for “code as content” - like UI code. Rust’s async story is awful. Pin is confusing. Async doesn’t play nice with other rust features (like traits). There’s no async streams and it’s extremely difficult to code your own. Solutions to these problems (like GAT and TAIT) have been proposed, coded and discussed for 6 years or something but they still haven’t shipped. I’m quite frustrated with how slowly the language is moving to fix obvious problems. And it seems to be getting slower as more people try to “help” (by chiming in on GitHub). But I really like rust-sans-async as a language for infrastructure code. The stuff I’ve built with it is bonkers fast, safe and correct. The crates ecosystem is fantastic. (Much higher quality than npm). And the community is smart and lovely. It’s not the most productive language but it fits the “better C” niche really well.
the_duke 4y ago
Isn't all the discussion about the top level UX a bit of a red herring? Iced, slint, sycamore, Dioxus , yew ... they all have quite different but very workable API surfaces. Yes, three of those target the browser, but there's nothing stopping them from building on a lower level Rust widget system instead. Even gtk-rs found a solid way to map a class structure to Rust extension traits. Isn't the real problem in the weak fundamentals? Solid window and input handling, text rendering, layouting and 2d drawing libraries, ... I see all the UI attempts struggling with those, and either implementing their own solutions or battling the existing ones (like winit). I feel like if all those pieces were in place decent solutions could emerge.
__david__ 4y ago
I just happened to build a little project using Slint (https://slint-ui.com/ https://slint-ui.com/) last week and found it fairly pleasant, even though it's got some rough edges still. I liked it because I was able to cross-compile to Windows from my Mac and from my Linux based CI with extreme ease ("cargo build --release --target x86_64-pc-windows-gnu"). It supposedly has some sort of native widgets available if you have Qt installed, but I haven't pursued that yet. It has a little meta language for describing the UI that gets compiled when you compile the code and that was nice because it catches type and syntax errors at compile time. I almost went with Tauri, but the cross-compile story didn't seem quite as good compared to Slint. Tauri does look nice though—web UIs are more flexible than Slint at this point. But for my simple little tool, Slint really hit the spot.
c-smile 4y ago
> The background for this is that most existing UI toolkits are a poor fit for Rust. Being in GUI business for almost 30+ years I shall admit that this above is true. And not just Rust but C/C++ are there too. Real (a.k.a. practical) GUIs are multi-paradigm entities. Same GUI implementation may have React'ive alike widgets immersed into purely declarative DOM/widget tree with elements of immediate mode graphics on top or inside that. It is just that GUI reflects complexity of real life - you cannot say that sickle and hammer are best tools for everything... Back to Rust... As a language behind UI Rust is the worst language imaginable. That's primarily due to its strictness. Object ownership graph in GUI is usually quite complex. yet it is dynamic and frequently contain loops. This situation is best handled by GCable languages. On-click-here-highlight-the-thing-there-and-remove-that-one. Also each part of UI declaration needs it's own DSL: for UI structure definition, style system and logic behind the UI. Before arriving with Sciter [1] I've tried [2] many things for UI: C++, D, Java, etc. Conclusion: HTML/CSS/JS is the best (most flexible and multi-paradigm) solution that we've got so far. Not perfect of course but good enough. And considering existence of Sciter it can be fast and lightweight. Practical example: RustDesk (https://github.com/rustdesk/ https://github.com/rustdesk/ - remote desktop access) is using Sciter for UI layer and Rust for app logic layer. So it is using proper tool for each task. [1] https://sciter.com https://sciter.com [2] https://terrainformatica.com/2014/07/17/10-years-road-to-sciter/ https://terrainformatica.com/2014/07/17/10-years-road-to-sci...
- gpm 4y ago
  > Also each part of UI declaration needs it's own DSL: for UI structure definition, style system and logic behind the UI. This is actually one thing I think rust has going for it, the procedural macro system makes it possible to embed reasonably arbitrary DSLs in rust.
  - c-smile 4y ago
    Rust can be good for implementation of UI system but as a language-behind-UI it is bad - its advantages (e.g. strictness) directly translate to disadvantages in that area. At the end, main idea of initial Rust design is to be the language with what browser is implemented. JavaScript (in ES2020 specification) is really good enough as UI automation language. If not JS then TS. Just in case in Sciter I've added native JSX to JS. JSX is an ergonomic way of defining tree alike literals that used for UI DOM population and patching.
ec109685 4y ago
The comparison of React Native to toolkits like Java’s AWT is incorrect given react native orchestrates the platform native UI toolkit, so the platform’s widgets will work similarly to other applications.
akagusu 4y ago
> while Electron continues to gain momentum Electron is not gaining momentum, it already is the standard. No matter what people try to invent, it needs to do all Electron does but ways better.
- nu11ptr 4y ago
  > No matter what people try to invent, it needs to do all Electron does but ways better. Tauri strikes me as a good step up from Electron, and likely a better fit for Rust users (as you can code everything except for view in Rust), but I have just started playing with it.
  - nextaccountic 4y ago
    > as you can code everything except for view in Rust You can do the whole stack in Rust, https://dev.to/stevepryde/create-a-desktop-app-in-rust-using-tauri-and-yew-2bhe https://dev.to/stevepryde/create-a-desktop-app-in-rust-using... https://github.com/jetli/rust-yew-axum-tauri-desktop https://github.com/jetli/rust-yew-axum-tauri-desktop
    - nu11ptr 4y ago
      I probably should have said "pure Rust" as you are mostly writing HTML/CSS, but yes, we could swap JS/TS there for Rust at least. It is just that for people like me who aren't gifted in HTML/CSS we need a UI library like MUI to help us out. Yew/Seed/etc. aren't mature enough to have a big ecosystem of mature UI libs (yet).
Const-me 4y ago
On Windows, the graphics story is more or less OK. The OS includes Direct2D and DirectWrite user-facing APIs. It’s now possible to implement an equivalent on all modern platforms which have a 3D GPU. An open-source example in C# https://github.com/Const-me/Vrmac#vector-graphics-engine https://github.com/Const-me/Vrmac#vector-graphics-engine That particular one requires GLES 3.1, but I’m sure (did it before) it’s also possible to implement comparable stuff on top of GLES2. Waiting for target devices to have TFlops of FP32 performance, and good support for compute shaders, is less than ideal. Many currently sold phones, tablets, laptops, and even some desktop PCs, have limited GPGPU capabilities and/or performance. These currently sold devices gonna stay in use for at least couple years in the future. Rendering things on CPU is less than ideal, because many devices have high-rez displays yet relatively slow CPU and especially RAM. Am I missing something? What’s the reason there’re no cross-platform GPU-first 2D graphics libraries, despite GLES2 (or better equivalents) is now universally available, and have been for years?
- stefan_ 4y ago
  Huh? That library exists, it is called Skia, it is the most premier 2D GPU (among other targets) rendering library in the world and it powers the Android UI, Chrome, Firefox and a ton of other things. See also: https://skia.org/ https://skia.org/
  - Const-me 4y ago
    Skia is not GPU first. It was initially designed for CPU-only rendering, 3D GPU support was an afterthought. For that reason, the quality of that support ain’t great. AFAIK it only uses 3D GPU to compose layers.
    - ReactiveJelly 4y ago
      No, I'm pretty sure it rasterizes using OpenGL ES, too. I don't know the code well enough to find good proof, but there's a lot of GLES and I think some DX calls in there. More than if it was just composing. https://github.com/google/skia/tree/main/src/gpu/ganesh/gl https://github.com/google/skia/tree/main/src/gpu/ganesh/gl
Animats 4y ago
I've been using egui->rend3->winit->wgpu->vulkan recently, with the goal of a program that will run on Windows, Mac, and Linux. It all mostly works. There's some dirty laundry revolving around full screen modes and window depth order, but it's not too bad. egui, an immediate mode GUI on top of winit, is interesting. It works OK, but only does part of the job. It displays the GUI widgets, but doing something with them is your problem. Usually, you need each widget to have some persistent state. Managing that state is the user's problem. So is generating, queuing, and distributing events to and from the GUI elements. There's also something strange which causes some scrolled windows to vibrate between two states. egui's default widgets are not very good looking. Light grey text on a dark grey background, super-thin scroll bars, that kind of thing. The aesthetics need work. Overall, though, not bad. This stuff just needs to be used more. It has not had enough attention and polishing. It's impressive that most of this works cross-platform, even cross-compiled. You don't even need a Windows machine to develop for a Windows target.
hvsuev 4y ago
OJFord 4y ago
This seems to implicitly mean low-level GUIs, or GUI frameworks? The only mention of Tauri is 'tao the fork of winit used by'. The article opens: > A few times a week, someone asks on the #gui-and-ui channel on the Rust Discord, “what is the best UI toolkit for my application?” Unfortunately there is still no clear answer to this question. I would say if by 'UI toolkit for my application' you just want a way to make a GUI app, not a game or some kind of highly native or specific interaction needs thing, just use Tauri. No idea why it's not a 'top contender', it has an order of magnitude more GH stars than Druid, for whatever that counts; I can only assume they mean lower-level toolkits. (No affiliation.) I just think someone new or unexposed to rust's going to see this and think it's way harder than it needs to be or is just to do something basic.
- raphlinus 4y ago
  That's fair. The main reason Tauri isn't higher on my radar is that if you're going to make an app based on the web technology stack, why not just use Electron? The tooling is mature, there's lots of knowledge, and you can use Rust modules (through wasm) easily enough. I suppose it depends on the actual use case, I'm sure there is a niche for Tauri, but it doesn't intersect use cases I'm interested in particularly.
  - OJFord 4y ago
    If someone into or getting into rust asked me 'how can I make a cross-platform app like with Electron', I would definitely say 'Tauri'; not 'actually you can use Electron with rust modules (through wasm) easily enough'. Unless perhaps they're also big into the JS ecosystem anyway. That 'mature tooling' you mention is npm/yarn/etc. stuff; Tauri's is cargo.
  - curun1r 4y ago
    AIUI, the major difference between the two is that Tauri uses the system’s WebView while Electron bundles a specific version of Chromium. That means Tauri will have a number of performance advantages at the cost of not being able to target a specific browser. Still, the “why not use Electron?” answer is that Electron is much more hostile to the user…much larger download size, slower startup and increased memory usage. With Rust valuing zero-cost abstractions, Tauri comes a lot closer to that ethos than Electron.
magicalhippo 4y ago
> What subset of expected text control functionality is provided? Missing from this otherwise great list, is basic system-standard text navigation and editing. I get so annoyed when basic stuff like ctrl+end or ctrl+v doesn't work like they should.
- raphlinus 4y ago
  Thanks! I might add that explicitly, but meant it to be included under "keyboard shortcuts according to platform human interface guidelines".
  - magicalhippo 4y ago
    I think explicit might be better, because it goes beyond that. For example, pressing ctrl+v while having text highlighted should replace the text on Windows, but doesn't always with non-native editors. edit: btw, great article. I've worked on a cross-platform application (Windows, Linux, OSX) which went from using wxWidgets to Qt. Quite painful either way, and while Qt was a fair bit better on OSX at the time we still had to use tons of ifdefs and per-platform configuration. And while I've been a win32 GUI programmer for decades, I totally get why people reach for Electron or embedded web servers. It's a really hard problem space with lots of trade-offs to be made.
hsbauauvhabzb 4y ago
What’s actually wrong with electron, or makes electron slow? I feel like every ‘UI frameworks suck’ posts glosses over this, but no real indication of why.
- boberoni 4y ago
  Most complaints about Electron that I see are about memory usage. If you’re running on an old laptop with little RAM, running 3+ Electron apps can start to slow your entire system down. There’s also a breed of users who are extremely sensitive to the “native feel” of a desktop app. For them, it’s a jarring experience to downgrade to something that is less snappy, but they expect a certain standard of snappiness.
- josephcsible 4y ago
  Because every Electron app is basically its own Web browser with all of the app's code being JavaScript, rather than the app just being native code. Try running Chrome, Edge, and Safari all at the same time and look what that does to your computer's resource usage. Electron apps basically do the exact same thing.
lewisjoe 4y ago
I like how the ecosystem around Kotlin has approached the problem. 1. The language itself has a way of introducing compiler plugins that lets you express your own tree structures in a succint syntax (comparable to macros in Rust I guess) 2. Then they figured out most UIs are trees and came up with a Flutter-like UI tree declaration API with react-like re-renders. Thus Android Compose was born! This went mainstream because most android devs fell in love with this new way of writing GUI 3. Like flutter, they are slowly exposing Skia (underlying rendering engine) APIs as kotlin wrappers - I guess the project's name is Skiko 4. Now with all these pieces they are building a full-fledged UI toolkit that renders over every platform (including web) - Jetpack Compose
- pjmlp 4y ago
  Meaning Android team, no ecosystem to speak of. There are even ADB episodes speaking about all those steps.
liquidnitrogen1 4y ago
Regarding Electron, i don't understand why anyone would want to go this route. I work in finance and desktop native apps (Winforms, WPF) have far more mature libraries, better performance and time to market compared to web GUIs. With Electron, we first write web apps and then wrap inside electron and then reinvent the wheel - this is so stupid.
- speedgoose 4y ago
  You only support windows, electron is multiplatform. About time to market it depends on your team. I don’t think there is a big difference between C#/WPF and TypeScript/React. But the second option works on more platforms and you will find competent developers a lot more easily.
- 1wd 4y ago
  WPF is now open source (MIT licensed [1]), and its XAML control templates provide _as data_ a full declarative description of how a native Windows control is supposed to look like (in multiple Windows themes like Aero for Win7, Aero2 for Win10, Luna + Royale for WinXP, and Classic for Win95 look and feel [2]). This includes everything like the exact colors and gradient stops and animation timing and vector shapes and accessibility behavior etc. of buttons and scrollbars and everything. Example: [3] I wonder what one could learn / achieve trying to "port WPF to rust" / implement a XAML control template renderer in Rust. If you can "simply" parse and interpret those XAML files do you instantly get a native-like GUI that supports the exact look and feel of these different Windows themes? (on any OS!) Somehow I think it is not realized how amazing that is! [1] https://github.com/dotnet/wpf/blob/main/LICENSE.TXT https://github.com/dotnet/wpf/blob/main/LICENSE.TXT [2] https://github.com/dotnet/wpf/tree/main/src/Microsoft.DotNet.Wpf/src/Themes https://github.com/dotnet/wpf/tree/main/src/Microsoft.DotNet... [3] https://github.com/dotnet/wpf/blob/main/src/Microsoft.DotNet.Wpf/src/Themes/PresentationFramework.Luna/Themes/Luna.NormalColor.xaml#L4274 https://github.com/dotnet/wpf/blob/main/src/Microsoft.DotNet...
  - ComputerGuru 4y ago
    I’ve had similar thoughts and starting writing my own rust XAML framework with exchangeable backends (backend implementations incomplete) but didn’t find much interest from the community despite how awesome XAML is at separating the UI from the toolkit.
malkia 4y ago
The elephant in the room for big CAD/CAM apps is dockable widgets, where (for me personally), the "standard" is how Visaul Studio does it. Even Qt, with it's built-in widgets is not enough (e.g. no multiple widgets/windows in non-main window), but there are some extensions/libraries/hacks to go around. Recently, few years ago, imgui got proper support for these too. And flutter has one or more design docs around it - e.g. multi-window support, which might be the stepping stone to these. Desktop apps are always going to be important in this space. Our game editor (Radiant) relies on this functionality when you use two, three or even more monitors.
- PoignardAzur 4y ago
  Can you develop? I understand the term "dockable widgets", but I'm not sure I'm visualizing the same UI as you.
  - johnofthesea 4y ago
    Something like Photoshop/Gimp panels I guess.
  - malkia 4y ago
    Something like this - https://github.com/nucleic/enaml#dock-item-alerts https://github.com/nucleic/enaml#dock-item-alerts - this is a Python UI that has the capability (extended through Qt)
- nyanpasu64 4y ago
  Surprisingly enough, Qt's built-in docking system has not one but two actively-maintained open-source third-party alternatives, KDDockWidgets and Qt-Advanced-Docking-System. (QtitanDocking is a commercial third-party docking system.)
OtomotO 4y ago
I somehow have a hunch that actors could be a good fit for the graph vs tree problem. Maybe it is time for some experiments
randyrand 4y ago
Why not copy the design of Flutter? Why reinvent the wheel?

345 points by raphlinus 4y ago

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 https://github.com/AccessKit/accesskit

favorited 4y ago
This is a really interesting project. Accessibility support is near and dear to my heart. The readme mentions a macOS adapter prototype, but I don't see that directory. Does it exist in a different branch? I'd love to check it out – I'm pretty experienced with the Mac's AX implementation, but have basically no experience with AX on Windows...
- mwcampbell 4y ago
  Oh wow, the readme is even more out of date than I realized. I yanked the Mac adapter prototype from the main branch last year. You can find it if you dig through history. I'll bring it back and continue working on it later this year; it's already on my schedule of work to do this year.
password4321 4y ago
Do you have a Patreon/whatever setup, since "this is the way" per baby Yoda?
- mwcampbell 4y ago
  Not yet. But Google is funding my work on AccessKit again this year. I'll write a blog post about that work later.

billconan 4y ago

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.

zachrip 4y ago
What are some of the difficulties?
- billconan 4y ago
  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 4y ago
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.
- raphlinus 4y ago
  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 4y ago

This advice is applicable to anyone building cross-platform UI toolkits, not just to Rust.

stephc_int13 4y ago

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 4y ago
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 4y ago
  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 4y ago
Maybe you know this, but he already released an MVP for a GUI library: https://github.com/linebender/druid https://github.com/linebender/druid
- stephc_int13 4y ago
  Not an MVP but an early demo, from my point of view.

game-of-throws 4y ago

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.

layer8 4y ago
The article mentioned scrolling. Do you get smooth scrolling with that approach, when the child window is conceptually embedded into a scrollable view? I guess you should, because the traditional Windows controls are technically all windows (HWND), but I wonder.
raphlinus 4y ago
I could probably have written this in a clearer way. Child windows like a proto-compositor in a way, just with more limitations. You can put video/3D/etc content in a child window, but there are serious tradeoffs. When it's in a scrolling container, either your scrolling implementation is built from child windows, or you're going to deal with less than perfect synchronization as you overlay a changing clip/translate for the embedded content with draws of the rest of your UI (this used to be a common problem in browsers). Modern compositor APIs have explicit transactions[1, 2] causing the various view changes to be applied at the same time. It's not that the problem can't be solved, it's that it's trickier than people imagine. And of course a Wayland subsurface is using the compositor. [1]: https://docs.microsoft.com/en-us/windows/win32/directcomp/basic-concepts#synchronization https://docs.microsoft.com/en-us/windows/win32/directcomp/ba... [2]: https://developer.apple.com/documentation/quartzcore/catransaction https://developer.apple.com/documentation/quartzcore/catrans...
c-smile 4y ago
I am participating now in such project - 3D CAD alike application: it renders 3D scene in Vulkan with Sciter rendering auxiliary UI on the same Vulkan surface. Sciter manages dockable widgets, property editors, scene tree logical representation, menus, etc. on top of 3D scene. Approach is explained here: https://sciter.com/sciter-and-directx/ https://sciter.com/sciter-and-directx/ You see there exactly 3D, video and GUI around.

pornel 4y ago

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.

kelseyfrog 4y ago
Is there an ECS-compatible ontology for UI components?
- bowsamic 4y ago
  In the post the author says the first architecture for Druid was ECS but they gave it up
jchw 4y ago
The thing is, there do exist UI frameworks that prefer composition over inheritance and strictly tree shaped components where data only flows one way: they're all the rage on the web. And that's great, because they give plenty of useful insight into things that work and don't work when designing UI frameworks this way. To be fair, it's not exactly like nobody realized this. More than one Rust desktop UI framework is explicitly React inspired, and it's not like FRP-based UI was non-existent prior to being popularized in web frameworks. Still, all the same... I suspect the best answers for how to do good UI in Rust are not far away from this paradigm.
- 4y ago

seanalltogether 4y ago

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.

favorited 4y ago
I think the industry at large is moving in the opposite direction, towards declarative layouts written in code. As an example, for decades, Apple's UI design tooling (Interface Builder) was serialized to XML, but SwiftUI uses a DSL so your interfaces are written in code. I haven't been a web developer professionally for a while, but I've dabbled in React, where you build UI components in JSX, which is an extension of JavaScript. I don't see why Rust couldn't be successful with a similar approach.

favorited 4y ago

> On macOS ... going forward, it’s likely that new capabilities and evolutions of the design language will be provided for the latter [SwiftUI] but not the former [AppKit]. I think this is vastly over-stating the technical churn of UI development on macOS. While we're definitely seeing new UI toolkits introduced that are Swift-only (like the new Charts.framework[0]), nearly every Mac app Apple ships is written using AppKit. For example, I just verified (`otool -l PATH_TO_APP_BINARY`) that Mail, App Store, Notes, Music, Xcode[1], and Photos all link against AppKit, and none link against SwiftUI (on macOS 12.4 21F79, which I'm running). There is, in my opinion, approximately zero chance that Apple either: (A) rewrites all of the UI in all of their apps, replacing AppKit with SwiftUI, in even the medium-term, or (B) starts treating AppKit apps as second-class citizens by introducing a new design language only available from SwiftUI. Yes, we're going to keep seeing cool new widgets and features which are only available from Swift. No, the platform's design language is not going change in a way that makes AppKit apps obsolete. [0]https://developer.apple.com/documentation/Charts https://developer.apple.com/documentation/Charts [1]I bet Xcode links SwiftUI somewhere for IDE integration, but I'm specifically referring to the UI implementation, parts of which have been in development since, like, NeXTSTEP and are certainly built using Objective-C & AppKit.

jolux 4y ago
Aren't App Store and Photos Mac Catalyst apps?
- favorited 4y ago
  Nope! Both are fully native macOS apps, at least on the version of Monterey that I'm running. You can examine which frameworks a binary links by running `otool -l /System/Applications/Photos.app/Contents/MacOS/Photos`. Traditional macOS Cocoa apps will link AppKit, while Catalyst apps will link UIKit. For example, if you run that command with a Catalyst app (e.g., Messages or Maps), you'll see that those apps link against `/System/iOSSupport/System/Library/Frameworks/UIKit.framework/Versions/A/UIKit`, and AppKit is nowhere to be found.
  - 4y ago

rustqt6 4y ago

Fwiw, I've head a great time with rust qmetaobject for some (basic) GUIs. Qt is more polished than any non-concerted (or even concerted) effort is going to be in at least half a decade

riquito 4y ago

Raphlinus, great post as usual, thanks for sharing your knowledge, is always an interesting read. I'm loosely following the progress of slint ui (formerly SixtyFPS), anything interesting in their approach or does it strictly matches one of your examples?

raphlinus 4y ago
I don't follow slint as closely as maybe I should. I'm definitely happy there's a real product out there, and would be happy to work with them on common infrastructure, but we haven't had much interaction (yet).

hardwaresofton 4y ago

Bit of a hot take, but I basically expect that most new Rust GUI projects will be written in Tauri before long. It works on multiple platforms, and is flexible, and it's easier to find off the shelf pieces due to the web technology involved, and it's lighter than Electron. It's a no-brainer for me (and others, I think) if I'm starting a new GUI desktop project.

tmpfs 4y ago
I think you are right about this with the one huge problem from my point of view being the text rendering on Windows. This is of course a problem with the Webview implementation on Windows but it is so awful it makes me want to use something else instead. Note this is not a reflection on Tauri which I think is awesome but Microsoft really should fix it.
- favorited 4y ago
  Is there something blocking Tauri from switching to WebView2 on Windows? It's based on Chromium, so I assume most of the legacy web view issues would be irrelevant. IIRC, WebView2 is supported going back to Windows 7...
  - nguyenkien 4y ago
    Tauri use webview2 on Windows
- oldmanhorton 4y ago
  Tauri uses WebView2 on windows, I believe, which should have the same text rendering as the Windows 11 start menu and Edge itself. You may be thinking of older IE-based webviews, which were used even well after "old edge" webviews were introduced because "old edge" webviews weren't supported on windows 7 or 8.
xvilka 4y ago
Hopefully, not. From my personal experience, Electron and alike applications are slower, larger, and in general have less advanced UI than many Qt or GTK-based (or Windows UI) applications. Nothing can beat good old native GUI frameworks.

asiachick 4y ago

> Instead of trying to decide whether a GUI toolkit is native or not, I recommend asking a set of more precise questions: > > * Does text look like the platform native text? > > * To what extent does the app support preferences set at the system level? > > * What subset of expected text control functionality is provided? > > * Complex text rendering including BiDi > > * Support for keyboard layouts including “dead key” for alphabetic scripts > > * Keyboard shortcuts according to platform human interface guidelines > > * Input Method Editor > > * Color emoji rendering and use of platform emoji picker > > * Copy-paste (clipboard) > > * Drag and drop > > * Spelling and grammar correction > > * Accessibility (including reading the text aloud) > > If a toolkit does well on all these axes, then I don’t think it much matters it’s built with “native” technology; that’s basically internal details. That said, it’s also very hard to hit all these points if there is a huge stack of non-native abstractions in the way. This is it! Browsers handle all of this. It's a ton of work. Many many gui kits start with just ASCII and really don't realize how deep the rabbit hole is for making all of this work. And as always, if you haven't read them https://gankra.github.io/blah/text-hates-you/ https://gankra.github.io/blah/text-hates-you/ https://lord.io/text-editing-hates-you-too/ https://lord.io/text-editing-hates-you-too/

overgard 4y ago

I think the web really killed the idea of "native" widgets. I think the rise of web apps just got everyone used to the idea that controls are just going to look different everywhere. Even on macOS, practically every app I use has a very distinct look and set of widgets (vscode, photoshop, blender, spotify -- two of those are electron, but even the non-electron stuff doesn't look very much like a "mac" app anymore). And in windows, microsoft really killed it themselves by constantly updating their own apps with non-standard widgets that everyone else wanted to clone (I remember the longest time it seemed like the only new things of note in every new version of ms office was how the toolbars looked). I suppose it's not a terrible thing, but I do kinda miss the days of windows 2000 and classic macos where the platform had a (somewhat) uniform look and feel.

wmf 4y ago
I think it's more a desire for branded UI rather than Web apps. Adobe wants their UIs to be instantly identifiable as Adobe, Slack wants to be instantly identifiable as Slack, MS Office as you said, etc. Personally, I doubt this benefits users (do you really need to market to people who already bought your product?) but I'm sure the logic is compelling to decision makers and it's cheaper to "design once, run everywhere". It also makes sense to developers that their app should look the same across OSes even though that "consistency" doesn't affect the 99% of users who only use one OS.
- Nadya 4y ago
  What's funny is that it pisses off a large number of those 1% of users who swap OSs frequently as well. So it isn't even for the benefit of that 1% either. When operating a Mac I expect Mac-specific behaviors. When operating a Windows PC I expect Windows-specific behaviors. I LOATHE programs that decide to do away with OS-isms that I am accustomed to and require me to learn how to "do things their way" because they wanted cross-OS consistency. Sometimes this means conforming everything to a single platform which is partially evil but just as often it means conforming to _none of them_ which is pure evil. But I understand this - as a web developer I've experienced pressure from Project Managers and the "decision makers" to make things consistent across browsers/devices even if doing so goes against how the users of said browsers/devices would expect things to operate - breaking user expectations and creating a worse UX for many users. I fight against it when I can but I'm not always successful.

CrimsonVoid 4y ago

I know this is going to be a controversial opinion considering how much everyone seems to love Rust, but does anyone else find Rust incredibly painful to work with, even for simple tasks? Like I'm no stranger to unmanaged languages, and to some extent I cut my teeth on C, but doing anything with Rust always feels like the most aggravating exercise in needless verbosity and the "Lombok problem" doesn't help either. (Funnily enough, both these reasons are why I don't like Java either). I don't want to sound too negative, Rust is a very promising language, but even seven(!) years later it still feels like a pre-alpha language.

avgcorrection 4y ago
Why would people be annoyed? Plenty of people have done the same thing in this thread. Except they stayed on the GUI topic. So maybe that’s why you included the sheepish intro sentence.
cturtle 4y ago
Yes I do find it painful. Because rust’s memory safety restricts the number of valid programs, it is (to me) more difficult to write code. That’s not a bad thing though! It’s just not a trade off I’m willing to make most of the time. If my project requires the memory safety that rust offers, I’ll choose rust. But most of the time I’ll pick something else to lower my mental load when coding.
__david__ 4y ago
I don't find that. I was quite familiar with C and C++ before learning Rust and I find the places where Rust requires explicitness are the places where C lets you glide by and inject hidden bugs into your code. When my Rust code finally compiles it has an extremely high percentage chance to _just work_, where when C compiles you still have another whole pass of "find all the segfaults lurking around".
josephg 4y ago
I learned rust a few years ago, and almost all the code I’ve written in the last 18 months has been rust. Rust makes you deal with all the pain of learning it up front. Does that pain ever go away? In my experience, it mostly does. I’m now significantly more productive in rust than C, and I feel much more pleased with the end result. I still find it takes a lot more effort to write rust than javascript though. Both more thinking per line, and it often takes more lines of code. The resulting software is faster and more correct, but it’s not a uniform win. I still reach for javascript for “code as content” - like UI code. Rust’s async story is awful. Pin is confusing. Async doesn’t play nice with other rust features (like traits). There’s no async streams and it’s extremely difficult to code your own. Solutions to these problems (like GAT and TAIT) have been proposed, coded and discussed for 6 years or something but they still haven’t shipped. I’m quite frustrated with how slowly the language is moving to fix obvious problems. And it seems to be getting slower as more people try to “help” (by chiming in on GitHub). But I really like rust-sans-async as a language for infrastructure code. The stuff I’ve built with it is bonkers fast, safe and correct. The crates ecosystem is fantastic. (Much higher quality than npm). And the community is smart and lovely. It’s not the most productive language but it fits the “better C” niche really well.

the_duke 4y ago

Isn't all the discussion about the top level UX a bit of a red herring? Iced, slint, sycamore, Dioxus , yew ... they all have quite different but very workable API surfaces. Yes, three of those target the browser, but there's nothing stopping them from building on a lower level Rust widget system instead. Even gtk-rs found a solid way to map a class structure to Rust extension traits. Isn't the real problem in the weak fundamentals? Solid window and input handling, text rendering, layouting and 2d drawing libraries, ... I see all the UI attempts struggling with those, and either implementing their own solutions or battling the existing ones (like winit). I feel like if all those pieces were in place decent solutions could emerge.

__david__ 4y ago

I just happened to build a little project using Slint (https://slint-ui.com/ https://slint-ui.com/) last week and found it fairly pleasant, even though it's got some rough edges still. I liked it because I was able to cross-compile to Windows from my Mac and from my Linux based CI with extreme ease ("cargo build --release --target x86_64-pc-windows-gnu"). It supposedly has some sort of native widgets available if you have Qt installed, but I haven't pursued that yet. It has a little meta language for describing the UI that gets compiled when you compile the code and that was nice because it catches type and syntax errors at compile time. I almost went with Tauri, but the cross-compile story didn't seem quite as good compared to Slint. Tauri does look nice though—web UIs are more flexible than Slint at this point. But for my simple little tool, Slint really hit the spot.

c-smile 4y ago

> The background for this is that most existing UI toolkits are a poor fit for Rust. Being in GUI business for almost 30+ years I shall admit that this above is true. And not just Rust but C/C++ are there too. Real (a.k.a. practical) GUIs are multi-paradigm entities. Same GUI implementation may have React'ive alike widgets immersed into purely declarative DOM/widget tree with elements of immediate mode graphics on top or inside that. It is just that GUI reflects complexity of real life - you cannot say that sickle and hammer are best tools for everything... Back to Rust... As a language behind UI Rust is the worst language imaginable. That's primarily due to its strictness. Object ownership graph in GUI is usually quite complex. yet it is dynamic and frequently contain loops. This situation is best handled by GCable languages. On-click-here-highlight-the-thing-there-and-remove-that-one. Also each part of UI declaration needs it's own DSL: for UI structure definition, style system and logic behind the UI. Before arriving with Sciter [1] I've tried [2] many things for UI: C++, D, Java, etc. Conclusion: HTML/CSS/JS is the best (most flexible and multi-paradigm) solution that we've got so far. Not perfect of course but good enough. And considering existence of Sciter it can be fast and lightweight. Practical example: RustDesk (https://github.com/rustdesk/ https://github.com/rustdesk/ - remote desktop access) is using Sciter for UI layer and Rust for app logic layer. So it is using proper tool for each task. [1] https://sciter.com https://sciter.com [2] https://terrainformatica.com/2014/07/17/10-years-road-to-sciter/ https://terrainformatica.com/2014/07/17/10-years-road-to-sci...

gpm 4y ago
> Also each part of UI declaration needs it's own DSL: for UI structure definition, style system and logic behind the UI. This is actually one thing I think rust has going for it, the procedural macro system makes it possible to embed reasonably arbitrary DSLs in rust.
- c-smile 4y ago
  Rust can be good for implementation of UI system but as a language-behind-UI it is bad - its advantages (e.g. strictness) directly translate to disadvantages in that area. At the end, main idea of initial Rust design is to be the language with what browser is implemented. JavaScript (in ES2020 specification) is really good enough as UI automation language. If not JS then TS. Just in case in Sciter I've added native JSX to JS. JSX is an ergonomic way of defining tree alike literals that used for UI DOM population and patching.

ec109685 4y ago

The comparison of React Native to toolkits like Java’s AWT is incorrect given react native orchestrates the platform native UI toolkit, so the platform’s widgets will work similarly to other applications.

akagusu 4y ago

> while Electron continues to gain momentum Electron is not gaining momentum, it already is the standard. No matter what people try to invent, it needs to do all Electron does but ways better.

nu11ptr 4y ago
> No matter what people try to invent, it needs to do all Electron does but ways better. Tauri strikes me as a good step up from Electron, and likely a better fit for Rust users (as you can code everything except for view in Rust), but I have just started playing with it.
- nextaccountic 4y ago
  > as you can code everything except for view in Rust You can do the whole stack in Rust, https://dev.to/stevepryde/create-a-desktop-app-in-rust-using-tauri-and-yew-2bhe https://dev.to/stevepryde/create-a-desktop-app-in-rust-using... https://github.com/jetli/rust-yew-axum-tauri-desktop https://github.com/jetli/rust-yew-axum-tauri-desktop
  - nu11ptr 4y ago
    I probably should have said "pure Rust" as you are mostly writing HTML/CSS, but yes, we could swap JS/TS there for Rust at least. It is just that for people like me who aren't gifted in HTML/CSS we need a UI library like MUI to help us out. Yew/Seed/etc. aren't mature enough to have a big ecosystem of mature UI libs (yet).

Const-me 4y ago

On Windows, the graphics story is more or less OK. The OS includes Direct2D and DirectWrite user-facing APIs. It’s now possible to implement an equivalent on all modern platforms which have a 3D GPU. An open-source example in C# https://github.com/Const-me/Vrmac#vector-graphics-engine https://github.com/Const-me/Vrmac#vector-graphics-engine That particular one requires GLES 3.1, but I’m sure (did it before) it’s also possible to implement comparable stuff on top of GLES2. Waiting for target devices to have TFlops of FP32 performance, and good support for compute shaders, is less than ideal. Many currently sold phones, tablets, laptops, and even some desktop PCs, have limited GPGPU capabilities and/or performance. These currently sold devices gonna stay in use for at least couple years in the future. Rendering things on CPU is less than ideal, because many devices have high-rez displays yet relatively slow CPU and especially RAM. Am I missing something? What’s the reason there’re no cross-platform GPU-first 2D graphics libraries, despite GLES2 (or better equivalents) is now universally available, and have been for years?

stefan_ 4y ago
Huh? That library exists, it is called Skia, it is the most premier 2D GPU (among other targets) rendering library in the world and it powers the Android UI, Chrome, Firefox and a ton of other things. See also: https://skia.org/ https://skia.org/
- Const-me 4y ago
  Skia is not GPU first. It was initially designed for CPU-only rendering, 3D GPU support was an afterthought. For that reason, the quality of that support ain’t great. AFAIK it only uses 3D GPU to compose layers.
  - ReactiveJelly 4y ago
    No, I'm pretty sure it rasterizes using OpenGL ES, too. I don't know the code well enough to find good proof, but there's a lot of GLES and I think some DX calls in there. More than if it was just composing. https://github.com/google/skia/tree/main/src/gpu/ganesh/gl https://github.com/google/skia/tree/main/src/gpu/ganesh/gl

Animats 4y ago

I've been using egui->rend3->winit->wgpu->vulkan recently, with the goal of a program that will run on Windows, Mac, and Linux. It all mostly works. There's some dirty laundry revolving around full screen modes and window depth order, but it's not too bad. egui, an immediate mode GUI on top of winit, is interesting. It works OK, but only does part of the job. It displays the GUI widgets, but doing something with them is your problem. Usually, you need each widget to have some persistent state. Managing that state is the user's problem. So is generating, queuing, and distributing events to and from the GUI elements. There's also something strange which causes some scrolled windows to vibrate between two states. egui's default widgets are not very good looking. Light grey text on a dark grey background, super-thin scroll bars, that kind of thing. The aesthetics need work. Overall, though, not bad. This stuff just needs to be used more. It has not had enough attention and polishing. It's impressive that most of this works cross-platform, even cross-compiled. You don't even need a Windows machine to develop for a Windows target.

hvsuev 4y ago

OJFord 4y ago

This seems to implicitly mean low-level GUIs, or GUI frameworks? The only mention of Tauri is 'tao the fork of winit used by'. The article opens: > A few times a week, someone asks on the #gui-and-ui channel on the Rust Discord, “what is the best UI toolkit for my application?” Unfortunately there is still no clear answer to this question. I would say if by 'UI toolkit for my application' you just want a way to make a GUI app, not a game or some kind of highly native or specific interaction needs thing, just use Tauri. No idea why it's not a 'top contender', it has an order of magnitude more GH stars than Druid, for whatever that counts; I can only assume they mean lower-level toolkits. (No affiliation.) I just think someone new or unexposed to rust's going to see this and think it's way harder than it needs to be or is just to do something basic.

raphlinus 4y ago
That's fair. The main reason Tauri isn't higher on my radar is that if you're going to make an app based on the web technology stack, why not just use Electron? The tooling is mature, there's lots of knowledge, and you can use Rust modules (through wasm) easily enough. I suppose it depends on the actual use case, I'm sure there is a niche for Tauri, but it doesn't intersect use cases I'm interested in particularly.
- OJFord 4y ago
  If someone into or getting into rust asked me 'how can I make a cross-platform app like with Electron', I would definitely say 'Tauri'; not 'actually you can use Electron with rust modules (through wasm) easily enough'. Unless perhaps they're also big into the JS ecosystem anyway. That 'mature tooling' you mention is npm/yarn/etc. stuff; Tauri's is cargo.
- curun1r 4y ago
  AIUI, the major difference between the two is that Tauri uses the system’s WebView while Electron bundles a specific version of Chromium. That means Tauri will have a number of performance advantages at the cost of not being able to target a specific browser. Still, the “why not use Electron?” answer is that Electron is much more hostile to the user…much larger download size, slower startup and increased memory usage. With Rust valuing zero-cost abstractions, Tauri comes a lot closer to that ethos than Electron.

magicalhippo 4y ago

> What subset of expected text control functionality is provided? Missing from this otherwise great list, is basic system-standard text navigation and editing. I get so annoyed when basic stuff like ctrl+end or ctrl+v doesn't work like they should.

raphlinus 4y ago
Thanks! I might add that explicitly, but meant it to be included under "keyboard shortcuts according to platform human interface guidelines".
- magicalhippo 4y ago
  I think explicit might be better, because it goes beyond that. For example, pressing ctrl+v while having text highlighted should replace the text on Windows, but doesn't always with non-native editors. edit: btw, great article. I've worked on a cross-platform application (Windows, Linux, OSX) which went from using wxWidgets to Qt. Quite painful either way, and while Qt was a fair bit better on OSX at the time we still had to use tons of ifdefs and per-platform configuration. And while I've been a win32 GUI programmer for decades, I totally get why people reach for Electron or embedded web servers. It's a really hard problem space with lots of trade-offs to be made.

hsbauauvhabzb 4y ago

What’s actually wrong with electron, or makes electron slow? I feel like every ‘UI frameworks suck’ posts glosses over this, but no real indication of why.

boberoni 4y ago
Most complaints about Electron that I see are about memory usage. If you’re running on an old laptop with little RAM, running 3+ Electron apps can start to slow your entire system down. There’s also a breed of users who are extremely sensitive to the “native feel” of a desktop app. For them, it’s a jarring experience to downgrade to something that is less snappy, but they expect a certain standard of snappiness.
josephcsible 4y ago
Because every Electron app is basically its own Web browser with all of the app's code being JavaScript, rather than the app just being native code. Try running Chrome, Edge, and Safari all at the same time and look what that does to your computer's resource usage. Electron apps basically do the exact same thing.

lewisjoe 4y ago

I like how the ecosystem around Kotlin has approached the problem. 1. The language itself has a way of introducing compiler plugins that lets you express your own tree structures in a succint syntax (comparable to macros in Rust I guess) 2. Then they figured out most UIs are trees and came up with a Flutter-like UI tree declaration API with react-like re-renders. Thus Android Compose was born! This went mainstream because most android devs fell in love with this new way of writing GUI 3. Like flutter, they are slowly exposing Skia (underlying rendering engine) APIs as kotlin wrappers - I guess the project's name is Skiko 4. Now with all these pieces they are building a full-fledged UI toolkit that renders over every platform (including web) - Jetpack Compose

pjmlp 4y ago
Meaning Android team, no ecosystem to speak of. There are even ADB episodes speaking about all those steps.

liquidnitrogen1 4y ago

Regarding Electron, i don't understand why anyone would want to go this route. I work in finance and desktop native apps (Winforms, WPF) have far more mature libraries, better performance and time to market compared to web GUIs. With Electron, we first write web apps and then wrap inside electron and then reinvent the wheel - this is so stupid.

speedgoose 4y ago
You only support windows, electron is multiplatform. About time to market it depends on your team. I don’t think there is a big difference between C#/WPF and TypeScript/React. But the second option works on more platforms and you will find competent developers a lot more easily.
1wd 4y ago
WPF is now open source (MIT licensed [1]), and its XAML control templates provide _as data_ a full declarative description of how a native Windows control is supposed to look like (in multiple Windows themes like Aero for Win7, Aero2 for Win10, Luna + Royale for WinXP, and Classic for Win95 look and feel [2]). This includes everything like the exact colors and gradient stops and animation timing and vector shapes and accessibility behavior etc. of buttons and scrollbars and everything. Example: [3] I wonder what one could learn / achieve trying to "port WPF to rust" / implement a XAML control template renderer in Rust. If you can "simply" parse and interpret those XAML files do you instantly get a native-like GUI that supports the exact look and feel of these different Windows themes? (on any OS!) Somehow I think it is not realized how amazing that is! [1] https://github.com/dotnet/wpf/blob/main/LICENSE.TXT https://github.com/dotnet/wpf/blob/main/LICENSE.TXT [2] https://github.com/dotnet/wpf/tree/main/src/Microsoft.DotNet.Wpf/src/Themes https://github.com/dotnet/wpf/tree/main/src/Microsoft.DotNet... [3] https://github.com/dotnet/wpf/blob/main/src/Microsoft.DotNet.Wpf/src/Themes/PresentationFramework.Luna/Themes/Luna.NormalColor.xaml#L4274 https://github.com/dotnet/wpf/blob/main/src/Microsoft.DotNet...
- ComputerGuru 4y ago
  I’ve had similar thoughts and starting writing my own rust XAML framework with exchangeable backends (backend implementations incomplete) but didn’t find much interest from the community despite how awesome XAML is at separating the UI from the toolkit.

malkia 4y ago

The elephant in the room for big CAD/CAM apps is dockable widgets, where (for me personally), the "standard" is how Visaul Studio does it. Even Qt, with it's built-in widgets is not enough (e.g. no multiple widgets/windows in non-main window), but there are some extensions/libraries/hacks to go around. Recently, few years ago, imgui got proper support for these too. And flutter has one or more design docs around it - e.g. multi-window support, which might be the stepping stone to these. Desktop apps are always going to be important in this space. Our game editor (Radiant) relies on this functionality when you use two, three or even more monitors.

PoignardAzur 4y ago
Can you develop? I understand the term "dockable widgets", but I'm not sure I'm visualizing the same UI as you.
- johnofthesea 4y ago
  Something like Photoshop/Gimp panels I guess.
- malkia 4y ago
  Something like this - https://github.com/nucleic/enaml#dock-item-alerts https://github.com/nucleic/enaml#dock-item-alerts - this is a Python UI that has the capability (extended through Qt)
nyanpasu64 4y ago
Surprisingly enough, Qt's built-in docking system has not one but two actively-maintained open-source third-party alternatives, KDDockWidgets and Qt-Advanced-Docking-System. (QtitanDocking is a commercial third-party docking system.)

OtomotO 4y ago

I somehow have a hunch that actors could be a good fit for the graph vs tree problem. Maybe it is time for some experiments

randyrand 4y ago

Why not copy the design of Flutter? Why reinvent the wheel?