19 ms·

Rust 2021: GUI

372 points by clarkmoody 6y ago

nixpulvis 6y ago
Having just started looking more into winit, I'm wondering how much different druid-shell is. There's a lot of similar ideas, and I know from working on a couple other projects that platform abstractions are often a nightmare to build and test. How does druid test across platforms like the web, Wayland, x11, macOS, Windows, etc? I feel like testing is one of the biggest missing links in the Rust GUI ecosystem right now.
- raphlinus 6y ago
  This is a very complicated issue. You can read our reasoning at the time in https://github.com/linebender/druid/issues/16 https://github.com/linebender/druid/issues/16 Since then, I've both regretted the fact that we're duplicating work, and been happy that we've been able to move more nimbly than we would if we were dragging the rest of the winit userbase along. A recent example of that is keyboard handling, and I'm expecting a similar situation soon with IME, as we'll want to handle that very differently than winit's current implementation. Take a look at our CI for the testing story. We have some tests, but they're mostly for platform-independent logic; we don't run a lot of platform specific code in CI. That said, Rust's type system is strong enough to catch a lot of potential breakage at compile time. Other than that, people tend to notice broken things pretty quickly. So overall testing is one of the many things we want to improve, but works reasonably well.
  - nixpulvis 6y ago
    If you don't mind, I'd love to hear more about what you are doing differently with keyboard handling (and IME support). I'm asking partly because I know this stuff is ripe with complexity and edge cases, and also because my head's in that space a bit right now, since I've been slowly fixing a bug in Alacritty that's been driving me crazy with modifiers at startup on X11.
    - raphlinus 6y ago
      On keyboard handling, https://github.com/linebender/druid/issues/1040 https://github.com/linebender/druid/issues/1040 is the main tracking issue. That references a number of PR's, of which 1049 is the core of the platform keyboard handling. I'd be very pleased for other people doing this (including winit) to use this as a model, as a fair amount of study went into getting it right, especially on Windows. Regarding IME, we haven't done it yet (we're trying to be fairly conservative in our roadmapping), but we plan to wire up actual composition regions and so on, and hope to plumb IME to it using a cross-platform abstraction. My understanding of the winit code is that it varies a lot from platform to platform, but seems to mostly be synthesizing keyboard events (ReceivedCharacter) when an IME request such as "insertText" happens.
shmerl 6y ago
> On Linux, Druid requires gtk+3 That kind of defeats the purpose? > Alternatively, there is an X11 backend available, although it is currently missing quite a few features. It would be good to also support Wayland compositors without GTK.
- duckerude 6y ago
  > That kind of defeats the purpose? Which purpose?
  - benrbray 6y ago
    Speaking as an outsider, I have been watching Rust very closely for two reasons: * I hope it will become a viable alternative to C/C++ for graphics programming. Unfortunately, last I checked as of ~6 months ago, Rust graphics libraries are still in their infancy. * I hope it will eventually replace Electron as the go-to for multiplatform app development. IMO this cannot realistically be done by relying on native APIs / platform-specific tools like GTK, since we need something closer to functional reactive programming a la React/Svelte/SolidJS, with more emphasis on performance. If I wanted to build a GTK app, I would build a GTK app. See also [1]. I believe Rust has the potential to accomplish both goals, partially due to the design of the language, but mostly because I have faith in the very smart people who work on Rust to make good decisions in the long-term. [1] https://raphlinus.github.io/rust/druid/2020/09/25/principled-reactive-ui.html https://raphlinus.github.io/rust/druid/2020/09/25/principled...
    - pascalshill 6y ago
      >I hope it will become a viable alternative to C/C++ for graphics programming This already exists, it is called Free Pascal + Lazarus.
      - benrbray 6y ago
        Care to elaborate? AFAIK C/C++ emerged as the alternative to Pascal way back when. No sense moving backwards--it's clear Rust is on track to displace several common uses for C/C++.
jonpalmisc 6y ago
A solid, production-grade GUI library would complete Rust for me. I reach for C++ and Qt when I want a cross-platform GUI and a low-level, compiled language. If Rust offered something on the same, or at least close, to Qt, I’d go all-in on Rust.
- kodablah 6y ago
  Same here on all points. I am familiar w/ existing options to create Qt bindings in Rust, yet like other non-Qt-backed bindings (i.e. not PySide), they fall into disrepair or suffer on often needed features such as inheritance and slots. I am kinda hoping autocxx[0] reaches the level of being able to handle wxWidgets headers (I have no hope for Qt though there are multiple Rust projects that try) and that will probably be enough for me on the desktop. Alternatively, it'd be nice to see a project that manually built Qt widget bindings surfacing an idiomatic Rust interface (kinda like what NodeGui does), but it's a lot of manual work that will have limited coverage in early stages instead of just continually improving/tweaking a generator. 0 - https://github.com/google/autocxx https://github.com/google/autocxx
  - adamnemecek 6y ago
    I hope that wxWidgets for Rust never sees the light of the day.
  - zozbot234 6y ago
    Doesn't wxWidgets have C-based bindings anyway, that Rust could use? How do they handle non-C++-based languages with existing support?
    - kodablah 6y ago
      I am only familiar w/ wxc which wxHaskell used[0], but I do not know if they are still maintained. Granted after your sibling commenter mentioned concerns w/ wxWidgets, I may have research to do on concerns with using it in 2020 (e.g. reading the references of https://en.wikipedia.org/wiki/WxWidgets#Criticism https://en.wikipedia.org/wiki/WxWidgets#Criticism). 0 - https://github.com/wxHaskell/wxHaskell/tree/master/wxc https://github.com/wxHaskell/wxHaskell/tree/master/wxc
neolog 6y ago
@raphlinus I'm curious if VR plays into your thinking for 3D?
- raphlinus 6y ago
  Not a lot, though I've had a number of really good conversations with the Servo team, who had been more focused on VR lately. Basically, I find VR mildly interesting, and will put significant effort into it if and when I'm funded for that :)
  - still_grokking 6y ago
    Sure, VR doesn't have mostly any serious applications. Some very special games and "virtual camp fires" is all I can think of. But AR has significant serious applications! I could imagine that there are quite some overlaps when it comes to parts of the core technology though, for example regarding VR / AR GUIs.
msoad 6y ago
A true winner Desktop GUI framework should target the web via WebAssembly. Accessibility of rendering everything in <canvas> is not an unsolvable problem. I also think targeting only desktop will avoid so much distraction that comes with targeting iOS and Android
- simias 6y ago
  If you're talking about rendering to a <canvas> instead of at least using the HTML DOM then you're not talking about a GUI toolkit really. You effectively just have a framebuffer and some primitives. That's not really what's being discussed here. If I just need a canvas to draw into I use the SDL, not GTK or Qt.
- jandrese 6y ago
  Doing this makes all of your applications similar to Electron apps. This is not a good thing. Nobody wants a desk calculator that requires 1GB of memory and takes 10 seconds to start. The amount of backend you need to implement a simple <canvas> is excessive for a great many apps.
raphlinus 6y ago
Why is every project on the HN front page these days Rust this, Rust that? I understand the enthusiasm, but sometimes it seems a bit much. Oh, this is my post. Never mind, carry on. More seriously, this was my contribution to the Rust 2021 blogging effort. I didn't really intend for it to be posted to HN, more as in internal discussion within the Rust community. Even so, I'm happy to discuss and answer questions. Read some more thoughts about Rust 2021 here: https://readrust.net/rust-2021 https://readrust.net/rust-2021
- gostsamo 6y ago
  Thanks for putting accessibility on the first row of priorities.
- benatkin 6y ago
  I think it's ideal content for HN. Programming languages have always been a big deal here, since the day HN was created.
  - throwaway894345 6y ago
    I certainly enjoy content like this a lot more than the "X startup exited for $Y million" content.
    - imtringued 6y ago
      Or the countless single person startups that shut down before you even knew of their existence.
  - acidbaseextract 6y ago
    I came to HN for the lisp fanboy culture when it washed out of reddit, and stayed for the great moderation.
- deleted 6y ago
  [deleted]
- andy_ppp 6y ago
adamnemecek 6y ago
You should check out femtovg, a canvas 2d API based on nanovg https://github.com/femtovg/femtovg https://github.com/femtovg/femtovg In some sense, the rendering API is the hard part of trying to build your own GUI toolkit.
seanalltogether 6y ago
Forgive my ignorance of Rust, but GUI toolkits are probably the strongest candidate for OOP style development, and everything I've read about Rust doesn't lend itself well to OOP. StyledObject -> View -> Text StyledObject -> View -> ViewContainer -> Button -> ToggleButton -> MyCustomToggleButton StyledObject -> View -> ViewContainer -> VerticalLayout -> ListView
- coldtea 6y ago
  >Forgive my ignorance of Rust, but GUI toolkits are probably the strongest candidate for OOP style development That's so 1991. We're on to GUI's as pure functions of state these days, get on with the program :-)
  - BlueTemplar 6y ago
    Tell us more ?
    - k__ 6y ago
      Cycle.js, Callbags, etc.
    - deleted 6y ago
      [deleted]
    - coldtea 6y ago
      Elm and React for one... and all the other similarly inspired UI libs (even SwiftUI is kind of going there)... Plus the increased interested on fp UIs for games, entity systems, etc... https://www.freecodecamp.org/news/the-revolution-of-pure-views-aed339db7da4/ https://www.freecodecamp.org/news/the-revolution-of-pure-vie...
    - 3PS 6y ago
      Check out these articles surveying the landscape of reactive UI, from the same author as the linked article: https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui.html https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui.... https://raphlinus.github.io/rust/druid/2020/09/25/principled-reactive-ui.html https://raphlinus.github.io/rust/druid/2020/09/25/principled...
adamnemecek 6y ago
You guys should check out rg3d https://github.com/mrDIMAS/rg3d https://github.com/mrDIMAS/rg3d it's a relatively advanced 3d engine with a ui toolkit https://github.com/mrDIMAS/rg3d-ui https://github.com/mrDIMAS/rg3d-ui and a scene editor https://github.com/mrDIMAS/rusty-editor https://github.com/mrDIMAS/rusty-editor Join the discord channel https://discord.gg/xENF5Uh https://discord.gg/xENF5Uh
brundolf 6y ago
One other aspect of Rust that makes it suited to GUI work is the fact that the management of mutable state is one of the core problems of writing a GUI app, and that Rust allows you to talk about mutation in a way that no other language (that I know of) does. You can a) have mutable structures, and b) declare that a function will treat one of those - passed as an argument - as deeply immutable, both within the same language. You can have exactly the amount of mutation that you want, which should be extremely enticing to any GUI developer.
- zozbot234 6y ago
  > deeply immutable Not really true, because the "interior mutability" pattern allows for mutating structures that are passed via a shared reference. Truly "immutable" data is in fact quite hard to characterize in a language that's as 'low-level' as Rust.
  - brundolf 6y ago
    Technically yes, there are trapdoors like RefCell. But these are intended to be used sparingly because they move all relevant borrow-checks to runtime. Under normal circumstances immutability is statically guaranteed by the ownership system, which is much more than can be said for other languages where mutability is an option at all.
    - Groxx 6y ago
      I suspect lifetimes get you the vast majority of the benefit of immutable data for UI purposes, tbh. It lets you ensure that references aren't retained or accessed at the wrong time, unless they provide an explicit way to bypass that (i.e. the defaults for data types is safe).
renewiltord 6y ago
Excited to see what comes here. If we can build some sort of React-like thing with a Redux like model, I think I would be very pleased. I find web development quite pleasing these days.
duhi88 6y ago
Any chance that the Servo renderer could leveraged for cross-platform GUIs as an alternative to Electron? I don't know if there would be any meaningful benefits over Electron, but I can see why it might be attractive to build everything in Rust. Seems like you could extend Servo with features required by your app, too.
- raphlinus 6y ago
  I've certainly been following Servo, and there are bits here and there where we've tried to share infrastructure, but ultimately we're making some pretty different decisions, mainly not to base things on Web technology so much, but align more with capabilities provided by the platform.
nwienert 6y ago
Safari has proved to me the web has potential to be much, much faster and more memory/battery efficient than most believe who just use Electron/Chrome. Projects like ultralight[0] also show there's even much higher room for improvement. That, and libraries like React starting to leverage WASM, and SharedArrayBuffers sharing memory and potentially moving all application logic off-thread (worker-dom is a cool project, I was able to get a medium-size React app fully running with it). Finally, you could fork Safari and remove quite a few features. A lot of legacy things, simplifying the DOM quite a lot, etc. If someone did that, I think we'd have a really ideal setup for cross platform apps. A much faster, lighter, smaller bundled app that supported 99% of modern web apps out of the box. [0] https://ultralig.ht https://ultralig.ht
- AgentEpsilon 6y ago
  Existing browser engines (Chromium, WebKit, Gecko) definitely have a lot of cruft in them for compatibility purposes. An engine designed to be much lighter weight and modern would be a great fit for embedding into applications. As opposed to writing a new engine from scratch (Servo), I wonder how feasible it would be to fork one of these existing engines and modularize its contents? The ability to start from (close to) zero and then pick and choose which features you want in your engine would be pretty attractive to lots of developers. The application that never expects to play any sort of media or access any peripherals could exclude the respective components from the build entirely.
- MrBuddyCasino 6y ago
  > Safari has proved to me the web has potential to be much, much faster and more memory/battery efficient than most believe who just use Electron/Chrome. I've been using Safari more recently and it really is a lot better than Chrome, and especially Firefox. I don't know how Apple does it, but they somehow made a Porsche in an SUV world. Thanks for the ultralig.ht pointer, looks quite interesting!
- thayne 6y ago
  > Finally, you could fork Safari and remove quite a few features. I'm really curious how you would fork a proprietary project. > If someone did that, I think we'd have a really ideal setup for cross platform apps. Buy safari isn't cross-platform.
Rexxar 6y ago
A wrapper around wxWidgets would be nice in my opinion. Every language community has a tendency to want a "pure" implementation of everything in their prefered language and utltimatly this just splits efforts and let everybody with half finished projects.
- brabel 6y ago
  Exactly! How much effort has been spent on UI kits already and we still have very few options, most as you say, half-finished! If only people had as much energy to help finish/improve existing, usable UI kits instead of re-inventing their own just for the glory of it. I have no doubt this effort will end up in the same exact way as the xi-editor (https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...) - a Rust text editor - did: huge amounts of work spent reinventing the wheel, one or two minor original contributions, but ultimately, ending far short of its goals and not delivering anything.
jscipione 6y ago
Lacking inheritance is a major stumbling block that rust will have to overcome in order to build an effective GUI. The earliest GUIs such as the object-pascal based Macintosh to the most modern ones rely on inheritance to function, so I wonder how the rust developers will overcome this limitation.
- dwohnitmok 6y ago
  I think the explosion of GUI frameworks for the web that don't rely on inheritance, or rely on it in only the most shallow of ways, demonstrates that inheritance is not essential for creating rich GUIs.
- epage 6y ago
  I've written a good number of GUI applicions and have found requiring inheritance is more of a limitation of the toolkit than inherent to the problem space. With PyGTK, I rarely, if ever inherit. With PyQT, I've had do to some abstractions to allow composition.
dan-robertson 6y ago
I wonder how event handling will look in whatever rust gui library wins out. What API alternatives are there to callbacks for widgets that may signal multiple events? One object would be to pass some implementation of some “Events” trait which would have methods to be called for each event kind. This is basically callbacks (I don’t think rust offers a way to make inline trait implementations and I don’t know if there’s a way to implicitly have default implementations that do nothing). This feels similar to in Java where you might subclass Button (I think. It’s been a while since I looked at any Java at all, let alone gui code). One way to deal with events is a more imgui-like api where you write e.g. if (make_button("click me")) { /* just been clicked */ } But I don’t see how this would work for lots of events (one option would be to have the return value be e.g. ButtonEvent option where the ButtonEvent type is an enum of all possible events a button may signal but there isn’t sub typing for variants so you either need lots of similar types for different controls and lots of pointless conversions or the types say that a control may signal events which it in fact never does. Also it may be possible to have multiple events hit a widget in a frame (eg mouseEnter, mouseMove; focus, mouseDown; mouseUp, click) so the option should be a sequence and you lose the ability to use “if let” when making the controls). A second issue is that this seems likely to add a frame of latency in many cases (eg if you have a wizard with a “next” buttons then you get the mouse event for the button being clicked by rerendering the dram as-is, and then on the next render you get to do the next page). Perhaps I should just look at the code to see what Druid and crochet do.
- raphlinus 6y ago
  We're still figuring this out, a discussion on the #crochet stream in our Zulip today is on this very topic. At a very high level though, many events (mouse movement, keyboard, etc) are handled by widgets, not by app logic, and those are dispatched to the widget by the toolkit calling into the widget Trait's `event` method. The idea that a button is clicked is different, we tend to call that an "action" rather than an event. In current Druid, it's a callback which is given access to mutable app state (often through a lens). In Crochet, it's placed in an "action queue" and the app logic is rerun when the queue is nonempty, then everything is rendered after the app logic has had a chance to make its mutations to the view tree. We don't have the one frame latency, as it's not imgui under the hood. (There's a bug in the Crochet prototype on this, but it's known and will be fixed). Hope this helps clear things up a bit.
nathell 6y ago
I haven't tried it out seriously yet, but vgtk (https://github.com/bodil/vgtk https://github.com/bodil/vgtk) seems to be an interesting approach to GUIs in Rust.
- timw4mail 6y ago
  I've tried it out a little bit, and the biggest problem is that it's implemented with deeply recursive macros. The concept is great, it seems to work, but there's no way you will ever have decent compile times.
msie 6y ago
I hope the debugging story for Rust gets better: https://nbaksalyar.github.io/2020/05/19/rust-debug.html https://nbaksalyar.github.io/2020/05/19/rust-debug.html
- IshKebab 6y ago
  The debugging story is pretty great already. Honestly that expression stuff he is talking about is pretty niche and very rarely works except for toy examples even in C++. Debugging Rust code in VSCode with Rust-analyzer and LLDB works pretty flawlessly for me, and it understands and displays all the types/values in the GUI so you don't really need expression evaluation.
  - pjmlp 6y ago
    Apparently I use plenty of toy examples on .NET, JShell, VSC++ immediate debugger and WinDBG consoles.
- deleted 6y ago
  [deleted]
rattray 6y ago
Naive question perhaps – what is missing in Gtk-rs?
- justaguy88 6y ago
  As a casual passer-by, I'd also like to know the trade-offs
- DesertVarnish 6y ago
  Packaging gtk for systems other than Linux can be a bit of a nightmare, and the experience on platforms other than Linux and desktop BSD leaves a lot to be desired.
- pjmlp 6y ago
  RAD tooling, not having to type Rc<RefCell<>> and clone everywhere (their samples even have a macro for it), or adding yet another library layer with relm.
zelly 6y ago
I don't remember the last time I installed a GUI desktop application. I think it might have been Zoom a couple years ago. If I install a desktop application that isn't some command line utility, it's a big deal, like a new girlfriend, feels like a committment. It better be a real appliance that actually requires access to hardware and would need to stay open most of the day. I struggle to think of the audience for these kinds of concerns about "desktop GUI". If the customer is enterprise, government, etc., then they will want WinForms/C# or Java/Swing and you simply don't get to pick Rust, Go, etc. If you just need a user interface, GUI nowadays means web or mobile (ideally SwiftUI). Let's face it, in 10 years, there aren't going to be many people using desktops. The people that will be using desktops (like me) probably will be fine with and prefer curses interfaces that run in a terminal emulator. There you go, that's your cross-platform GUI.
- rapsey 6y ago
  Enterprise clients do not care what GUI library an app uses. Desktops/laptops are alive and well and there is nothing on the horizon that replaces them.
andrew_shay 6y ago
Sciter is what I'm using, and I love it. It's not a pure Rust solution though. https://sciter.com/ https://sciter.com/
- techdragon 6y ago
  It’s worth mentioning that there’s currently a Kickstarter campaign to open source Sciter https://www.kickstarter.com/projects/c-smile/open-source-sciter-engine https://www.kickstarter.com/projects/c-smile/open-source-sci... it’s by the author who seems to have some worthwhile goals for using the money besides simply opening up the code.
- imtringued 6y ago
  It looks great. I personally have nothing against HTML UIs other than electron's excessive resource usage. My primary complaint is that chrome's engine was never meant to be used once per application. Sciter fixes that.
c-smile 6y ago
Good GUI layer should be language agnostic. Reasons: 1. GUI is non-trivial. That is not just about problems of CPU/GPU rasterization (30...40% of all GUI problems). There are others that we usually forget about: accessibility, customization/styling, DPI and screen device size awarness, etc. 2. It makes no sense to invest in development of only-for-Rust GUI libraries. Just use in Rust something ready that has stable plain-C ABI. And so people from C/C++, Delphi can use it too. That would be more robust on the long run. 3. Rust is is not that good to be a language-behind-UI. Ownership graph of GUI objects can be quite complex, contain loops and can be not known at compile time. Something GCable plays significantly better in this respect. That's why JS is so popular in UI. Sciter's script is even better than JS but that's another story. So "GUI 2021" as a subject of blogging makes sense, but "Rust GUI 2021" is a bit hopeless I think.
- lmm 6y ago
  > 2. It makes no sense to invest in development of only-for-Rust GUI libraries. Just use in Rust something ready that has stable plain-C ABI. And so people from C/C++, Delphi can use it too. That would be more robust on the long run. Disagree. Anything that uses a C ABI has to keep track of ownership externally, and that tends to be error-prone; you end up with excessive copying, leaks, or both. And this is a particularly thorny problem for GUIs because, as you say, ownership of GUI objects can be complicated. So it makes a lot of sense to have a Rust-specific GUI library that leverages Rust's ownership-tracking capabilities to make this easier.
  - c-smile 6y ago
    UI and BL (business logic layer) can interact by messages. Think about Protocol Buffers (https://developers.google.com/protocol-buffers https://developers.google.com/protocol-buffers ) or JSON/BSON as a core of communication protocol // App side: window* pw = new Window(); pw->willReceiveMessage("account.modified", cb1); pw->willReceiveMessage("account.closed", cb2); pw->willReceiveMessage("account.wantsNew", cb3); .... pw->loadUI("accounts-view.htm"); .... pw->fireMessage("account.show", accountData: json) Messaging, as a concept, is simple and data ownership is crystal clear.
randyrand 6y ago
More effort needs to be put into porting existing GUI APIs to rust. Port UIkit, port Flutter. These APIs people already know. Electron is popular largely for this reason. Or do we just enjoy reinventing the wheel?
- wtetzner 6y ago
  The models those GUI APIs use have a pretty big impedance mismatch with the way Rust works.
  - randyrand 6y ago
    How to design a UI is a broad question that is independent of programming language. It does not need to be reinvented.
hardwaresofton 6y ago
For those looking for interesting rust GUI projects, I think the one that has stuck out the most in my memory is Conrod[0][1]. If I were to try and write a cross-platform single-binary 2D GUI application with rust these days, it's the first thing I'd pick. Unfortunately, I haven't done that, so whether it's the right choice for you is still up for debate. There's also stuff like gtk-rs[2] for those who want to have a bit more of a trusted gtk-flavored ecosystem. [0]: https://docs.rs/conrod_core/0.70.0/conrod_core/guide/chapter_1/index.html https://docs.rs/conrod_core/0.70.0/conrod_core/guide/chapter... [1]: https://github.com/PistonDevelopers/conrod https://github.com/PistonDevelopers/conrod [2]: https://gtk-rs.org/ https://gtk-rs.org/
fluffything 6y ago
This is more a topic for Rust 2020-2030 than Rust 2021.
Chuan2020 6y ago
Cool, I found the word that interesting relationship between 'rust' and 'trust'. The Rust team would be inclined to give the project a name like that?
bugeats 6y ago
My compromise has been to use [flutter-rs](https://github.com/flutter-rs/flutter-rs https://github.com/flutter-rs/flutter-rs). Flutter is a powerful and performant GUI/Drawing framework, even if you need to hold your nose when slinging Dart.
tabtab 6y ago
Rather then reinvent a GUI library for each language, what about creating a stateful open GUI Markup Language? Then you'd use XML to communicate with the GUI browser (or browser plug-in). That way any language can do real GUI's, and without screwy bloated buggy JavaScript libraries.

Rust 2021: GUI

372 points by clarkmoody 6y ago

Having just started looking more into winit, I'm wondering how much different druid-shell is. There's a lot of similar ideas, and I know from working on a couple other projects that platform abstractions are often a nightmare to build and test. How does druid test across platforms like the web, Wayland, x11, macOS, Windows, etc? I feel like testing is one of the biggest missing links in the Rust GUI ecosystem right now.

raphlinus 6y ago
This is a very complicated issue. You can read our reasoning at the time in https://github.com/linebender/druid/issues/16 https://github.com/linebender/druid/issues/16 Since then, I've both regretted the fact that we're duplicating work, and been happy that we've been able to move more nimbly than we would if we were dragging the rest of the winit userbase along. A recent example of that is keyboard handling, and I'm expecting a similar situation soon with IME, as we'll want to handle that very differently than winit's current implementation. Take a look at our CI for the testing story. We have some tests, but they're mostly for platform-independent logic; we don't run a lot of platform specific code in CI. That said, Rust's type system is strong enough to catch a lot of potential breakage at compile time. Other than that, people tend to notice broken things pretty quickly. So overall testing is one of the many things we want to improve, but works reasonably well.
- nixpulvis 6y ago
  If you don't mind, I'd love to hear more about what you are doing differently with keyboard handling (and IME support). I'm asking partly because I know this stuff is ripe with complexity and edge cases, and also because my head's in that space a bit right now, since I've been slowly fixing a bug in Alacritty that's been driving me crazy with modifiers at startup on X11.
  - raphlinus 6y ago
    On keyboard handling, https://github.com/linebender/druid/issues/1040 https://github.com/linebender/druid/issues/1040 is the main tracking issue. That references a number of PR's, of which 1049 is the core of the platform keyboard handling. I'd be very pleased for other people doing this (including winit) to use this as a model, as a fair amount of study went into getting it right, especially on Windows. Regarding IME, we haven't done it yet (we're trying to be fairly conservative in our roadmapping), but we plan to wire up actual composition regions and so on, and hope to plumb IME to it using a cross-platform abstraction. My understanding of the winit code is that it varies a lot from platform to platform, but seems to mostly be synthesizing keyboard events (ReceivedCharacter) when an IME request such as "insertText" happens.

shmerl 6y ago

> On Linux, Druid requires gtk+3 That kind of defeats the purpose? > Alternatively, there is an X11 backend available, although it is currently missing quite a few features. It would be good to also support Wayland compositors without GTK.

duckerude 6y ago
> That kind of defeats the purpose? Which purpose?
- benrbray 6y ago
  Speaking as an outsider, I have been watching Rust very closely for two reasons: * I hope it will become a viable alternative to C/C++ for graphics programming. Unfortunately, last I checked as of ~6 months ago, Rust graphics libraries are still in their infancy. * I hope it will eventually replace Electron as the go-to for multiplatform app development. IMO this cannot realistically be done by relying on native APIs / platform-specific tools like GTK, since we need something closer to functional reactive programming a la React/Svelte/SolidJS, with more emphasis on performance. If I wanted to build a GTK app, I would build a GTK app. See also [1]. I believe Rust has the potential to accomplish both goals, partially due to the design of the language, but mostly because I have faith in the very smart people who work on Rust to make good decisions in the long-term. [1] https://raphlinus.github.io/rust/druid/2020/09/25/principled-reactive-ui.html https://raphlinus.github.io/rust/druid/2020/09/25/principled...
  - pascalshill 6y ago
    >I hope it will become a viable alternative to C/C++ for graphics programming This already exists, it is called Free Pascal + Lazarus.
    - benrbray 6y ago
      Care to elaborate? AFAIK C/C++ emerged as the alternative to Pascal way back when. No sense moving backwards--it's clear Rust is on track to displace several common uses for C/C++.

jonpalmisc 6y ago

A solid, production-grade GUI library would complete Rust for me. I reach for C++ and Qt when I want a cross-platform GUI and a low-level, compiled language. If Rust offered something on the same, or at least close, to Qt, I’d go all-in on Rust.

kodablah 6y ago
Same here on all points. I am familiar w/ existing options to create Qt bindings in Rust, yet like other non-Qt-backed bindings (i.e. not PySide), they fall into disrepair or suffer on often needed features such as inheritance and slots. I am kinda hoping autocxx[0] reaches the level of being able to handle wxWidgets headers (I have no hope for Qt though there are multiple Rust projects that try) and that will probably be enough for me on the desktop. Alternatively, it'd be nice to see a project that manually built Qt widget bindings surfacing an idiomatic Rust interface (kinda like what NodeGui does), but it's a lot of manual work that will have limited coverage in early stages instead of just continually improving/tweaking a generator. 0 - https://github.com/google/autocxx https://github.com/google/autocxx
- adamnemecek 6y ago
  I hope that wxWidgets for Rust never sees the light of the day.
- zozbot234 6y ago
  Doesn't wxWidgets have C-based bindings anyway, that Rust could use? How do they handle non-C++-based languages with existing support?
  - kodablah 6y ago
    I am only familiar w/ wxc which wxHaskell used[0], but I do not know if they are still maintained. Granted after your sibling commenter mentioned concerns w/ wxWidgets, I may have research to do on concerns with using it in 2020 (e.g. reading the references of https://en.wikipedia.org/wiki/WxWidgets#Criticism https://en.wikipedia.org/wiki/WxWidgets#Criticism). 0 - https://github.com/wxHaskell/wxHaskell/tree/master/wxc https://github.com/wxHaskell/wxHaskell/tree/master/wxc

neolog 6y ago

@raphlinus I'm curious if VR plays into your thinking for 3D?

raphlinus 6y ago
Not a lot, though I've had a number of really good conversations with the Servo team, who had been more focused on VR lately. Basically, I find VR mildly interesting, and will put significant effort into it if and when I'm funded for that :)
- still_grokking 6y ago
  Sure, VR doesn't have mostly any serious applications. Some very special games and "virtual camp fires" is all I can think of. But AR has significant serious applications! I could imagine that there are quite some overlaps when it comes to parts of the core technology though, for example regarding VR / AR GUIs.

msoad 6y ago

A true winner Desktop GUI framework should target the web via WebAssembly. Accessibility of rendering everything in <canvas> is not an unsolvable problem. I also think targeting only desktop will avoid so much distraction that comes with targeting iOS and Android

simias 6y ago
If you're talking about rendering to a <canvas> instead of at least using the HTML DOM then you're not talking about a GUI toolkit really. You effectively just have a framebuffer and some primitives. That's not really what's being discussed here. If I just need a canvas to draw into I use the SDL, not GTK or Qt.
jandrese 6y ago
Doing this makes all of your applications similar to Electron apps. This is not a good thing. Nobody wants a desk calculator that requires 1GB of memory and takes 10 seconds to start. The amount of backend you need to implement a simple <canvas> is excessive for a great many apps.

raphlinus 6y ago

Why is every project on the HN front page these days Rust this, Rust that? I understand the enthusiasm, but sometimes it seems a bit much. Oh, this is my post. Never mind, carry on. More seriously, this was my contribution to the Rust 2021 blogging effort. I didn't really intend for it to be posted to HN, more as in internal discussion within the Rust community. Even so, I'm happy to discuss and answer questions. Read some more thoughts about Rust 2021 here: https://readrust.net/rust-2021 https://readrust.net/rust-2021

gostsamo 6y ago
Thanks for putting accessibility on the first row of priorities.
benatkin 6y ago
I think it's ideal content for HN. Programming languages have always been a big deal here, since the day HN was created.
- throwaway894345 6y ago
  I certainly enjoy content like this a lot more than the "X startup exited for $Y million" content.
  - imtringued 6y ago
    Or the countless single person startups that shut down before you even knew of their existence.
- acidbaseextract 6y ago
  I came to HN for the lisp fanboy culture when it washed out of reddit, and stayed for the great moderation.
deleted 6y ago
[deleted]
andy_ppp 6y ago

adamnemecek 6y ago

You should check out femtovg, a canvas 2d API based on nanovg https://github.com/femtovg/femtovg https://github.com/femtovg/femtovg In some sense, the rendering API is the hard part of trying to build your own GUI toolkit.

seanalltogether 6y ago

Forgive my ignorance of Rust, but GUI toolkits are probably the strongest candidate for OOP style development, and everything I've read about Rust doesn't lend itself well to OOP. StyledObject -> View -> Text StyledObject -> View -> ViewContainer -> Button -> ToggleButton -> MyCustomToggleButton StyledObject -> View -> ViewContainer -> VerticalLayout -> ListView

coldtea 6y ago
>Forgive my ignorance of Rust, but GUI toolkits are probably the strongest candidate for OOP style development That's so 1991. We're on to GUI's as pure functions of state these days, get on with the program :-)
- BlueTemplar 6y ago
  Tell us more ?
  - k__ 6y ago
    Cycle.js, Callbags, etc.
  - deleted 6y ago
    [deleted]
  - coldtea 6y ago
    Elm and React for one... and all the other similarly inspired UI libs (even SwiftUI is kind of going there)... Plus the increased interested on fp UIs for games, entity systems, etc... https://www.freecodecamp.org/news/the-revolution-of-pure-views-aed339db7da4/ https://www.freecodecamp.org/news/the-revolution-of-pure-vie...
  - 3PS 6y ago
    Check out these articles surveying the landscape of reactive UI, from the same author as the linked article: https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui.html https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui.... https://raphlinus.github.io/rust/druid/2020/09/25/principled-reactive-ui.html https://raphlinus.github.io/rust/druid/2020/09/25/principled...

adamnemecek 6y ago

You guys should check out rg3d https://github.com/mrDIMAS/rg3d https://github.com/mrDIMAS/rg3d it's a relatively advanced 3d engine with a ui toolkit https://github.com/mrDIMAS/rg3d-ui https://github.com/mrDIMAS/rg3d-ui and a scene editor https://github.com/mrDIMAS/rusty-editor https://github.com/mrDIMAS/rusty-editor Join the discord channel https://discord.gg/xENF5Uh https://discord.gg/xENF5Uh

brundolf 6y ago

One other aspect of Rust that makes it suited to GUI work is the fact that the management of mutable state is one of the core problems of writing a GUI app, and that Rust allows you to talk about mutation in a way that no other language (that I know of) does. You can a) have mutable structures, and b) declare that a function will treat one of those - passed as an argument - as deeply immutable, both within the same language. You can have exactly the amount of mutation that you want, which should be extremely enticing to any GUI developer.

zozbot234 6y ago
> deeply immutable Not really true, because the "interior mutability" pattern allows for mutating structures that are passed via a shared reference. Truly "immutable" data is in fact quite hard to characterize in a language that's as 'low-level' as Rust.
- brundolf 6y ago
  Technically yes, there are trapdoors like RefCell. But these are intended to be used sparingly because they move all relevant borrow-checks to runtime. Under normal circumstances immutability is statically guaranteed by the ownership system, which is much more than can be said for other languages where mutability is an option at all.
  - Groxx 6y ago
    I suspect lifetimes get you the vast majority of the benefit of immutable data for UI purposes, tbh. It lets you ensure that references aren't retained or accessed at the wrong time, unless they provide an explicit way to bypass that (i.e. the defaults for data types is safe).

renewiltord 6y ago

Excited to see what comes here. If we can build some sort of React-like thing with a Redux like model, I think I would be very pleased. I find web development quite pleasing these days.

duhi88 6y ago

Any chance that the Servo renderer could leveraged for cross-platform GUIs as an alternative to Electron? I don't know if there would be any meaningful benefits over Electron, but I can see why it might be attractive to build everything in Rust. Seems like you could extend Servo with features required by your app, too.

raphlinus 6y ago
I've certainly been following Servo, and there are bits here and there where we've tried to share infrastructure, but ultimately we're making some pretty different decisions, mainly not to base things on Web technology so much, but align more with capabilities provided by the platform.

nwienert 6y ago

Safari has proved to me the web has potential to be much, much faster and more memory/battery efficient than most believe who just use Electron/Chrome. Projects like ultralight[0] also show there's even much higher room for improvement. That, and libraries like React starting to leverage WASM, and SharedArrayBuffers sharing memory and potentially moving all application logic off-thread (worker-dom is a cool project, I was able to get a medium-size React app fully running with it). Finally, you could fork Safari and remove quite a few features. A lot of legacy things, simplifying the DOM quite a lot, etc. If someone did that, I think we'd have a really ideal setup for cross platform apps. A much faster, lighter, smaller bundled app that supported 99% of modern web apps out of the box. [0] https://ultralig.ht https://ultralig.ht

AgentEpsilon 6y ago
Existing browser engines (Chromium, WebKit, Gecko) definitely have a lot of cruft in them for compatibility purposes. An engine designed to be much lighter weight and modern would be a great fit for embedding into applications. As opposed to writing a new engine from scratch (Servo), I wonder how feasible it would be to fork one of these existing engines and modularize its contents? The ability to start from (close to) zero and then pick and choose which features you want in your engine would be pretty attractive to lots of developers. The application that never expects to play any sort of media or access any peripherals could exclude the respective components from the build entirely.
MrBuddyCasino 6y ago
> Safari has proved to me the web has potential to be much, much faster and more memory/battery efficient than most believe who just use Electron/Chrome. I've been using Safari more recently and it really is a lot better than Chrome, and especially Firefox. I don't know how Apple does it, but they somehow made a Porsche in an SUV world. Thanks for the ultralig.ht pointer, looks quite interesting!
thayne 6y ago
> Finally, you could fork Safari and remove quite a few features. I'm really curious how you would fork a proprietary project. > If someone did that, I think we'd have a really ideal setup for cross platform apps. Buy safari isn't cross-platform.

Rexxar 6y ago

A wrapper around wxWidgets would be nice in my opinion. Every language community has a tendency to want a "pure" implementation of everything in their prefered language and utltimatly this just splits efforts and let everybody with half finished projects.

brabel 6y ago
Exactly! How much effort has been spent on UI kits already and we still have very few options, most as you say, half-finished! If only people had as much energy to help finish/improve existing, usable UI kits instead of re-inventing their own just for the glory of it. I have no doubt this effort will end up in the same exact way as the xi-editor (https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...) - a Rust text editor - did: huge amounts of work spent reinventing the wheel, one or two minor original contributions, but ultimately, ending far short of its goals and not delivering anything.

jscipione 6y ago

Lacking inheritance is a major stumbling block that rust will have to overcome in order to build an effective GUI. The earliest GUIs such as the object-pascal based Macintosh to the most modern ones rely on inheritance to function, so I wonder how the rust developers will overcome this limitation.

dwohnitmok 6y ago
I think the explosion of GUI frameworks for the web that don't rely on inheritance, or rely on it in only the most shallow of ways, demonstrates that inheritance is not essential for creating rich GUIs.
epage 6y ago
I've written a good number of GUI applicions and have found requiring inheritance is more of a limitation of the toolkit than inherent to the problem space. With PyGTK, I rarely, if ever inherit. With PyQT, I've had do to some abstractions to allow composition.

dan-robertson 6y ago

I wonder how event handling will look in whatever rust gui library wins out. What API alternatives are there to callbacks for widgets that may signal multiple events? One object would be to pass some implementation of some “Events” trait which would have methods to be called for each event kind. This is basically callbacks (I don’t think rust offers a way to make inline trait implementations and I don’t know if there’s a way to implicitly have default implementations that do nothing). This feels similar to in Java where you might subclass Button (I think. It’s been a while since I looked at any Java at all, let alone gui code). One way to deal with events is a more imgui-like api where you write e.g. if (make_button("click me")) { /* just been clicked */ } But I don’t see how this would work for lots of events (one option would be to have the return value be e.g. ButtonEvent option where the ButtonEvent type is an enum of all possible events a button may signal but there isn’t sub typing for variants so you either need lots of similar types for different controls and lots of pointless conversions or the types say that a control may signal events which it in fact never does. Also it may be possible to have multiple events hit a widget in a frame (eg mouseEnter, mouseMove; focus, mouseDown; mouseUp, click) so the option should be a sequence and you lose the ability to use “if let” when making the controls). A second issue is that this seems likely to add a frame of latency in many cases (eg if you have a wizard with a “next” buttons then you get the mouse event for the button being clicked by rerendering the dram as-is, and then on the next render you get to do the next page). Perhaps I should just look at the code to see what Druid and crochet do.

raphlinus 6y ago
We're still figuring this out, a discussion on the #crochet stream in our Zulip today is on this very topic. At a very high level though, many events (mouse movement, keyboard, etc) are handled by widgets, not by app logic, and those are dispatched to the widget by the toolkit calling into the widget Trait's `event` method. The idea that a button is clicked is different, we tend to call that an "action" rather than an event. In current Druid, it's a callback which is given access to mutable app state (often through a lens). In Crochet, it's placed in an "action queue" and the app logic is rerun when the queue is nonempty, then everything is rendered after the app logic has had a chance to make its mutations to the view tree. We don't have the one frame latency, as it's not imgui under the hood. (There's a bug in the Crochet prototype on this, but it's known and will be fixed). Hope this helps clear things up a bit.

nathell 6y ago

I haven't tried it out seriously yet, but vgtk (https://github.com/bodil/vgtk https://github.com/bodil/vgtk) seems to be an interesting approach to GUIs in Rust.

timw4mail 6y ago
I've tried it out a little bit, and the biggest problem is that it's implemented with deeply recursive macros. The concept is great, it seems to work, but there's no way you will ever have decent compile times.

msie 6y ago

I hope the debugging story for Rust gets better: https://nbaksalyar.github.io/2020/05/19/rust-debug.html https://nbaksalyar.github.io/2020/05/19/rust-debug.html

IshKebab 6y ago
The debugging story is pretty great already. Honestly that expression stuff he is talking about is pretty niche and very rarely works except for toy examples even in C++. Debugging Rust code in VSCode with Rust-analyzer and LLDB works pretty flawlessly for me, and it understands and displays all the types/values in the GUI so you don't really need expression evaluation.
- pjmlp 6y ago
  Apparently I use plenty of toy examples on .NET, JShell, VSC++ immediate debugger and WinDBG consoles.
deleted 6y ago
[deleted]

rattray 6y ago

Naive question perhaps – what is missing in Gtk-rs?

justaguy88 6y ago
As a casual passer-by, I'd also like to know the trade-offs
DesertVarnish 6y ago
Packaging gtk for systems other than Linux can be a bit of a nightmare, and the experience on platforms other than Linux and desktop BSD leaves a lot to be desired.
pjmlp 6y ago
RAD tooling, not having to type Rc<RefCell<>> and clone everywhere (their samples even have a macro for it), or adding yet another library layer with relm.

zelly 6y ago

I don't remember the last time I installed a GUI desktop application. I think it might have been Zoom a couple years ago. If I install a desktop application that isn't some command line utility, it's a big deal, like a new girlfriend, feels like a committment. It better be a real appliance that actually requires access to hardware and would need to stay open most of the day. I struggle to think of the audience for these kinds of concerns about "desktop GUI". If the customer is enterprise, government, etc., then they will want WinForms/C# or Java/Swing and you simply don't get to pick Rust, Go, etc. If you just need a user interface, GUI nowadays means web or mobile (ideally SwiftUI). Let's face it, in 10 years, there aren't going to be many people using desktops. The people that will be using desktops (like me) probably will be fine with and prefer curses interfaces that run in a terminal emulator. There you go, that's your cross-platform GUI.

rapsey 6y ago
Enterprise clients do not care what GUI library an app uses. Desktops/laptops are alive and well and there is nothing on the horizon that replaces them.

andrew_shay 6y ago

Sciter is what I'm using, and I love it. It's not a pure Rust solution though. https://sciter.com/ https://sciter.com/

techdragon 6y ago
It’s worth mentioning that there’s currently a Kickstarter campaign to open source Sciter https://www.kickstarter.com/projects/c-smile/open-source-sciter-engine https://www.kickstarter.com/projects/c-smile/open-source-sci... it’s by the author who seems to have some worthwhile goals for using the money besides simply opening up the code.
imtringued 6y ago
It looks great. I personally have nothing against HTML UIs other than electron's excessive resource usage. My primary complaint is that chrome's engine was never meant to be used once per application. Sciter fixes that.

c-smile 6y ago

Good GUI layer should be language agnostic. Reasons: 1. GUI is non-trivial. That is not just about problems of CPU/GPU rasterization (30...40% of all GUI problems). There are others that we usually forget about: accessibility, customization/styling, DPI and screen device size awarness, etc. 2. It makes no sense to invest in development of only-for-Rust GUI libraries. Just use in Rust something ready that has stable plain-C ABI. And so people from C/C++, Delphi can use it too. That would be more robust on the long run. 3. Rust is is not that good to be a language-behind-UI. Ownership graph of GUI objects can be quite complex, contain loops and can be not known at compile time. Something GCable plays significantly better in this respect. That's why JS is so popular in UI. Sciter's script is even better than JS but that's another story. So "GUI 2021" as a subject of blogging makes sense, but "Rust GUI 2021" is a bit hopeless I think.

lmm 6y ago
> 2. It makes no sense to invest in development of only-for-Rust GUI libraries. Just use in Rust something ready that has stable plain-C ABI. And so people from C/C++, Delphi can use it too. That would be more robust on the long run. Disagree. Anything that uses a C ABI has to keep track of ownership externally, and that tends to be error-prone; you end up with excessive copying, leaks, or both. And this is a particularly thorny problem for GUIs because, as you say, ownership of GUI objects can be complicated. So it makes a lot of sense to have a Rust-specific GUI library that leverages Rust's ownership-tracking capabilities to make this easier.
- c-smile 6y ago
  UI and BL (business logic layer) can interact by messages. Think about Protocol Buffers (https://developers.google.com/protocol-buffers https://developers.google.com/protocol-buffers ) or JSON/BSON as a core of communication protocol // App side: window* pw = new Window(); pw->willReceiveMessage("account.modified", cb1); pw->willReceiveMessage("account.closed", cb2); pw->willReceiveMessage("account.wantsNew", cb3); .... pw->loadUI("accounts-view.htm"); .... pw->fireMessage("account.show", accountData: json) Messaging, as a concept, is simple and data ownership is crystal clear.

randyrand 6y ago

More effort needs to be put into porting existing GUI APIs to rust. Port UIkit, port Flutter. These APIs people already know. Electron is popular largely for this reason. Or do we just enjoy reinventing the wheel?

wtetzner 6y ago
The models those GUI APIs use have a pretty big impedance mismatch with the way Rust works.
- randyrand 6y ago
  How to design a UI is a broad question that is independent of programming language. It does not need to be reinvented.

hardwaresofton 6y ago

For those looking for interesting rust GUI projects, I think the one that has stuck out the most in my memory is Conrod[0][1]. If I were to try and write a cross-platform single-binary 2D GUI application with rust these days, it's the first thing I'd pick. Unfortunately, I haven't done that, so whether it's the right choice for you is still up for debate. There's also stuff like gtk-rs[2] for those who want to have a bit more of a trusted gtk-flavored ecosystem. [0]: https://docs.rs/conrod_core/0.70.0/conrod_core/guide/chapter_1/index.html https://docs.rs/conrod_core/0.70.0/conrod_core/guide/chapter... [1]: https://github.com/PistonDevelopers/conrod https://github.com/PistonDevelopers/conrod [2]: https://gtk-rs.org/ https://gtk-rs.org/

fluffything 6y ago

This is more a topic for Rust 2020-2030 than Rust 2021.

Chuan2020 6y ago

Cool, I found the word that interesting relationship between 'rust' and 'trust'. The Rust team would be inclined to give the project a name like that?

bugeats 6y ago

My compromise has been to use [flutter-rs](https://github.com/flutter-rs/flutter-rs https://github.com/flutter-rs/flutter-rs). Flutter is a powerful and performant GUI/Drawing framework, even if you need to hold your nose when slinging Dart.

tabtab 6y ago

Rather then reinvent a GUI library for each language, what about creating a stateful open GUI Markup Language? Then you'd use XML to communicate with the GUI browser (or browser plug-in). That way any language can do real GUI's, and without screwy bloated buggy JavaScript libraries.