Been doing a lot of looking around different (graphic) user interface projects over the past year and I'm starting to build a better understanding of first things I think about or look for, mostly from a technical standpoint...
See other thread of replies for living list of criteria. My soft conclusion is that Electron is actually way ahead in the current landscape when you take the things I list into account, whether you like it or not 😄
I've noticed the following approaches when it comes to rendering:
fully native (via system native toolkit)
web-based (via system's webview)
canvas-based (have no idea how this is derived tbh 😅)
I see the benefits of the first two quite clearly. The canvas-based approach has never appealed to me, or at least I haven't seen any approaches that excite me
Accessibility: does it provide primitives that allow implementers to improve functionality with tools like assistive technologies, physical limitations, etc?
Internationalization: does it have mechanisms for integrating language preferences? e.g. how hard would it be to switch between RTL and LTR languages?
Portability: if it supports cross-platform, how does it approach it? Does it try to maintain visual consistency or does it prefer to adhere to platform-specific conventions?
@matt I'm pretty intrigued by @accesskit ! Curious if you have a list of various GUI projects and the state of their accessibility capabilities. My impression from perusing is that most fall really short or just entirely lack any way to hook into the native system's accessibility primitives.
@andrew_chou I think your impression is basically right.
The most mature option for cross-platform accessibility is, of course, the web stack. For desktop apps, this means using something like Electron or Tauri. Tauri is likely marginally better on macOS, since it uses Apple's own WebKit, but I've shipped an accessible Electron app on both Windows and macOS.
@andrew_chou Of the mature non-web cross-platform toolkits, the most accessible is probably Qt. But, anecdotally, it seems pretty easy to mess up accessibility in a Qt app.
AccessKit itself is still maturing. There are some widget types, like tables, tree views, and combo boxes, that we don't support well yet. I'm in the middle of integrating AccessKit into GTK (for non-Linux platforms and for a new prototype desktop Linux accessibility stack I'm developing).
@andrew_chou If you're interested in Rust GUI toolkits using AccessKit, the most fully accessible one so far is egui. It doesn't have some of those widget types I mentioned though (that's one reason why AccessKit doesn't yet support them; I need a real-world test case). I'm aware of one real-world egui application so far that's accessible thanks to AccessKit; coincidentally, it's an assistive technology (the Talon voice control app), so of course, its own UI needs to be accessible.
@matt yeah this is helpful! I'm not as deeply invested in the space as you are so appreciate you sharing your insights.
My hope is that younger projects can lean on AccessKit to get that part of the equation right, as I can imagine it's a huge undertaking (hence the lackluster state of the ecosystem).
Unfortunately not much of a Rust person when it comes to writing stuff, but happy to follow along regardless :)
@matt I mostly work in the web stack (have worked with Electron in the past), although been interested options for native GUI toolkits that live in Kotlin and Elixir ecosystems.
Slint also caught my eye, although I'd probably try their Node bindings if at all.
Add comment