ash VS egui

Nice and simple. Its quite portable too. But simplicity and ease of use come with some limitations. Ash is much more complex but can extract every bit of power from your card if needed. Wgpu-rs github comes with many examples and you can find a really nice tutorial here

low level vulkan bindings

Glium and ash provide low level access to different common graphics api's. I'm sure there's a good directx-11/12 bindings as well but I'm unfamiliar with what people use.

This project was inspired by the Bonzomatic, KodeLife and others, as well as in educational purposes to learn Vulkan using ash.

The closest thing to vulkan afaik is literally vulkan bindings, iirc I've seen the ash (https://github.com/MaikKlein/ash) crate recommended for that, but that is fairly unsafe.

I would not recommend vulkano, I would recommend ash, most serious projects that are targeting only vulkan (ie not using gfx-hal), use ash. Vulkano makes some odd decisions and their build process is a pain, if it works in c++, you might not be able to get it to work in Vulkano. Ash has the same exact dependencies you would need in a C++ rust project (ie just the vulkan sdk on windows), and most low level conversion stuff to rust (enums) is already done.

If you don’t mind just drawing into a rectangle (without native UI components), more options open up. There’s plenty of Rust libraries for just drawing into a buffer. Like https://github.com/emilk/egui, which does provide UI components, just not native one.

Besides a browser based GUI you have many other options like egui, Iced etc. In this case you can still use HTTP for communication between your programs, but also sockets, and, if the programs run on the same machine, named pipes and shared memory (which is more efficient for sharing big data chunks).

If you want to use separate codebases, then you might consider egui, iced or gtk-rs for the desktop part.

egui: this is technically a GUI framework, but it supports arbitrary rendering through a simple api, and you can also access the underlying graphics APIs if you want to. The eframe crate makes it easy to make an egui window.

A big thing keeping me on webview was accessibility - and with egui finally gaining AccessKit support, it spurred me into making some mockups, which I rather liked the look of.

I'd recommend giving egui a try: https://github.com/emilk/egui/. It aims to be very simple to use, and the repo contains several examples.

I've opened an issue! on Github.

The example is basically unchanged from 0.17 but now lives here: https://github.com/emilk/egui/tree/master/examples/custom_font

I can go into great detail here why but its beside the point. If you read my comment on the egui issue I linked above (same handle I use on HN) you may get an idea where I am coming from.

Most Human Computer Interface (HCI) guidlines for various platforms are based on typical late 90's early 2k desktop apps.

They were never updated to reflect on newer paradigmns for UX that evolved in recent years. Blame the fragmentation of the desktop and Electron & co.

IMHO this is the first problem the OS vendors need to solve before we can blame developers of UI libs to not make them look 'native enough'.

[1] https://github.com/emilk/egui/issues/88