egui VS gtk-rs

On the "immediate mode" front egui (Showcase gallery) seems to be gaining some level of "critical mass" in terms of uptake which has resulted in quite a wide variety of backend implementations (both "official" & 3rd party). This has had the benefit that you can use egui in a "low dependencies" context but also find it integrations implemented for bigger projects such as Bevy--so it's nice to have the ability to transfer one's egui knowledge into multiple contexts. (egui is also the Rust GUI crate with which I've had the most experience.).

egui (https://github.com/emilk/egui)

A simple TextEdit window with content being added from the bottom becomes blurry. What actually happens is that, at 60 FPS, alternate frames are displaced upwards slightly. A 30 FPS video capture looks fine, but a 60 FPS capture shows the problem. This worked in previous versions of egii, but is broken in 0.21.0. This may be related to a generic problem with "bottom up" mode in the layout engine. Egui has one-pass layout, done on each frame, but tries to do some things which are hard to do in one pass.

You could make the screenshot lovers very happy by adding some directly to both your Readme (I know there are some in the wiki) and to https://github.com/emilk/egui/issues/996

egui is excellent and runs in any browser that supports wasm.

Not true, even if you add Rust. egui was released earlier: https://github.com/emilk/egui

And egui isn't tied to Apple proprietary frameworks.

All that talk was about declarative UI approaches; on the other side there are Immediate-mode UIs that redraw everything several times per second, and work well enough with things like game engines. In that regard I believe https://github.com/emilk/egui/ is good enough for now.

I started trying to port the UI to egui, but gave up pretty quickly after realizing that it doesn't have a particularly good way to customize the style of widgets so it'd probably be pretty hard to get everything looking the way I wanted it to.

Concerning GUI frameworks, the most common ones are druid, egui and iced. All three of them run native and on the Web.

In a gtk-rs application, I'm running a xdotool command to get the id of the application's window. I'm running the command in a connect_show closure (after the window has been shown):

To build the UI, I used gtk-rs. My experience with this library was quite pleasant; it was easy to use and there were a lot of examples. However, it isn't as widely used as, say, React, so it was difficult to find answer on Stack Overflow (I come from a JavaScript/Typescript background).

I'm using x11rb to interact with a window created with gtk-rs. window_id is the ID of the window created with gtk-rs. window_id_2 is the ID of the window created with x11rb (for testing purposes).

I haven't used it yet, but gtk-rs looks pretty good too. I've used GTK in general, just not the Rust bindings so far. The tutorials seem nice and GTK is a good UI toolkit overall.

For GTK, there's https://gtk-rs.org/

Out there there are already some open source projects trying to do this, but most of them are abandoned or in a very alpha stage. The most promising project so far seems to me git-kt. This project is trying to do something similar to what gtk-rs does for Rust, which is using GObject Introspection (GIR) files to generate Kotlin native bindings automatically.

Currently, I have narrowed potential libraries to: 1. Flutter 2. FLTK 3. Relm (GTK) 4. iced 5. Slint 6. Imgui, Imgui-rs 7. and gtk-rs

and gtk-rs

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

The [gtk-rs](https://gtk-rs.org/) project provides GTK bindings for Rust.