Hacker Newsnew | past | comments | ask | show | jobs | submit | emilern's commentslogin

Good question. You can if you use this instead: https://huggingface.co/spaces/TencentARC/InstantMesh


Yes! egui uses https://github.com/AccessKit/accesskit for accessibility


Hi there - CTO of Rerun here!

Rerun is still in beta, but we think it’s already good enough to be useful. It is built on wgpu, Apache Arrow, my own egui.rs library, and it also runs as Wasm in the browser.

I'm happy to answer any questions you may have!

PS: Thanks for the shoutout fdb!


A bit tangential, but since you're using wgpu in your own product now, do you have any plans to switch to using wgpu by default in eframe, and possibly even eliminate glow? I'm just curious; this probably doesn't have any effect on anything I'm working on. Anyway, eliminating the multiple code paths in eframe would be nice.


Switching to wgpu as the default is a definite possibility, but something should be said for the simplicity of the glow backend. wgpu is a big beast, which takes more time to compile, and for a lot of eframe users it is simply over-kill.

…but then again, if you want simplicity and fast compiles, I can recommend the egui-miniquad backend. It's not as fully-featured as eframe, but with some love it could definitely get there.


A video of it working might be really good, it might make it clearer what this does.


I came across rerun from egui too. Egui is a very good marketing funnel.


Thank you <3


Hi - CTO of Rerun here.

We just open-sourced Rerun today! It’s still in beta, but we think it’s good enough to be useful. It is built on wgpu, Apache Arrow, my own egui.rs library, and it also runs as Wasm in the browser.

I'm happy to answer any questions you may have!


egui is an easy-to-use immediate mode GUI for Rust, and I just released 0.20. It's a big release!

There is now support for AccessKit (https://github.com/AccessKit/accesskit) which brings accessibility to egui (a first for an immediate mode GUI?).

There is also better table support, nicer keyboard shortcut handling, better looking text in light mode (still not great, but better).

See more in the changelog: https://github.com/emilk/egui/blob/master/CHANGELOG.md

Try it out at www.egui.rs


Thanks for working with me to get AccessKit support integrated.

I should note that the web demo isn't yet accessible, except with the built-in text-to-speech option that can currently only be enabled through the inaccessible UI itself. Not a complaint; just a clarification, since the parent comment mentioned both accessibility and the web demo. Sooner or later AccessKit will have a web platform adapter that will implement the usual parallel-DOM workaround for canvas-based apps.


The enum example in the article


OK, that's an interesting language feature, but I can't say it's something that I've often wanted to do in C++. Of course C++ does have std::variant and std::any, although I'm not really a fan. I'd tend to (and have) just use a class that contains the variants and an enum to track which one, then setters and getters.

event.SetKeyPress(ch);

event.SetMouseButtonPress(pos, but); etc

...

switch (event.type) {

case EvKeyPress: ch = event.GetKeyPress();


Of course the Rust features being used by that Event type are runtime polymorphism and type introspection, so another obvious C++ approach would be just to use a pointer to a virtual based class including the type, then:

switch (event->type) {

case EvKeyPressEvent:

  {

    auto kpe - dynamic_cast<KeyPressEvent*>(event)

    ...

  }

  break;

}


No, not right now!


Maybe later then :)


Hi, author here

Good point about the yanking. But yes, there are multiple other problems such as typosquatting and adding malicious code to a patch release. `cargo-crev` and `cargo-vet` are both interesting tools that I'm keeping my eye on.


Hi, author here!

We are building the frontend of our _application_ in Rust and rendering it to a canvas using egui.rs. For the web site we are using more "traditional" tech, as you've noticed.

I am not a big fan of the complexity of modern web sites (including our own), which is exactly why I created egui. However, it is targeted at web apps, not web sites.


I'm very curious how well this is working for you in practice, since I've been thinking about what it would look like to share a single Rust UI implementation across a webapp and native apps.


So far so good!

Putting the UI in a canvas elements have some distinct drawbacks (https://github.com/emilk/egui/tree/master/crates/eframe#prob...) but for us it is definitely worth it. Having one unified codebase for our web app and native app, and having it all in Rust, is just amazing.

We're currently working on a 3D renderer based on wgpu (https://github.com/gfx-rs/wgpu) that we will likewise use for both web and desktop.


How does egui interact with screen readers and other accessibility APIs?


So-so. There is an experimental screen reader you can enable in the "Backend" panel of egui.rs.

There is ongoing work to integrate AccessKit (https://github.com/AccessKit/accesskit) which will improve things significantly.


Anyone who's interested in the AccessKit integration can play with my work-in-progress branch: https://github.com/mwcampbell/egui/tree/accesskit

It's currently Windows-only, and I'm working on the big missing feature, which is text editing support.


Doesn’t dart/flutter do this? Render everything to a canvas.

It is difficult to believe this will be the future of the web.

I don’t think websites should take this approach. Seems like a bad idea


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: