4 ms·

I'm looking forward to seeing how this pans out. I've been working on some WGPU based rendering code the last year or so, and in lieu of any truly decent UI lib

I'm looking forward to seeing how this pans out. I've been working on some WGPU based rendering code the last year or so, and in lieu of any truly decent UI libraries on the Rust side (no offence to the existing players) I ended up going the Electron route, since my code was already compiling to WASM anyway. I also explored going the imgui and Qt routes, but Electron felt the most fully featured and easy to use. Still, it's Electron. I'm happy to see that Xilem is not blindly copying JS/Swift ideas (or 'adapting' them, as Raph says :)) but applying them in a way that feels very Rust native. They've been experimenting a lot the last few years and I really hope we're finally getting to that point where we go beyond experiments and into something useable!

speed_spread 3y ago
Since you're using Rust, did you consider using Tauri instead of full-on Electron?
- royjacobs 3y ago
  Yes, but at that time Tauri did not have support for WebGPU on MacOS. Also, the Electron community is substantially larger and since this is mostly a personal project speed of development and easy access to community forums were more important to me than things like install size.
jenadine 3y ago
There is also Slint
- royjacobs 3y ago
  Well sure, there are a lot of different options. But I wanted to pick a toolkit where there were already a lot of UI components available and I would haven't to hand roll a lot of them manually. For instance, my UI contains a node graph. Since I was using Electron I could simply use react-flow [0]. As part of my research I also implemented node graphs in both imgui and Qt and, while certainly possible, it is a lot of work to get all the interaction nuances right. The main drawback of using Electron was having to do a lot of interop work, of course, but as long as I was mostly working on the UI side I had all the benefits of hot reloading, existing design systems to pick and choose (I ultimately picked Mantine [1]), etc. [0] https://reactflow.dev/ https://reactflow.dev/ [1] https://mantine.dev/ https://mantine.dev/
- LoganDark 3y ago
  which is mainly designed for microcontrollers and doesn't support most accessibility or power-user features on desktop. For example their input fields are incredibly basic and seem to be entirely written in their high-level DSL which is foolishly ambitious.
  - tobias12345 3y ago
    There is accessibility using the Qt backend and I started working on accesskit integration, which should cover the rest of the backends. Yes, more work needs to be done there, but the architecture has proven that it works. Any help with accessibility is welcome, especially as I lack the experience of having to rely on accessibility features. I might miss some things that will be show-stoppers for people reliant on accessibility. Of course any help is appreciated, too ;-) All the text handling code is done in Rust (or C++, depending on the backend you pick). Just the basic navigation between elements and such is done in our DSL. But yes, we need more widgets and more features for some of the existing ones. We are working on that...

speed_spread 3y ago

Since you're using Rust, did you consider using Tauri instead of full-on Electron?

royjacobs 3y ago
Yes, but at that time Tauri did not have support for WebGPU on MacOS. Also, the Electron community is substantially larger and since this is mostly a personal project speed of development and easy access to community forums were more important to me than things like install size.

jenadine 3y ago

There is also Slint

royjacobs 3y ago
Well sure, there are a lot of different options. But I wanted to pick a toolkit where there were already a lot of UI components available and I would haven't to hand roll a lot of them manually. For instance, my UI contains a node graph. Since I was using Electron I could simply use react-flow [0]. As part of my research I also implemented node graphs in both imgui and Qt and, while certainly possible, it is a lot of work to get all the interaction nuances right. The main drawback of using Electron was having to do a lot of interop work, of course, but as long as I was mostly working on the UI side I had all the benefits of hot reloading, existing design systems to pick and choose (I ultimately picked Mantine [1]), etc. [0] https://reactflow.dev/ https://reactflow.dev/ [1] https://mantine.dev/ https://mantine.dev/
LoganDark 3y ago
which is mainly designed for microcontrollers and doesn't support most accessibility or power-user features on desktop. For example their input fields are incredibly basic and seem to be entirely written in their high-level DSL which is foolishly ambitious.
- tobias12345 3y ago
  There is accessibility using the Qt backend and I started working on accesskit integration, which should cover the rest of the backends. Yes, more work needs to be done there, but the architecture has proven that it works. Any help with accessibility is welcome, especially as I lack the experience of having to rely on accessibility features. I might miss some things that will be show-stoppers for people reliant on accessibility. Of course any help is appreciated, too ;-) All the text handling code is done in Rust (or C++, depending on the backend you pick). Just the basic navigation between elements and such is done in our DSL. But yes, we need more widgets and more features for some of the existing ones. We are working on that...