In the GTK+ 2.x era, I would have agreed with you. GTK+ was either the basis for or easily themeable to feel reasonably native under any Linux desktop environment and, because of the applications which depend on it, pretty much everyone is likely to have it already installed.
Unfortunately, in the GTK+ 3.x era and beyond, the perspective of many KDE users is that hell has frozen over because GTK+ has supplanted MacOS as the GUI with the most alien feel to it.
(Plus, the LXDE developers started a transition to GTK+ 3.x, got fed up, and decided that their upgrade path from GTK+ 2.x would be Qt 5. They then merged with Razor-Qt to form LXQt.)
Personally, what rubs me the wrong way the most is the various ways in which it explicitly goes against what HCI research recommends because the GNOME people just liked it better their way. (And I've read quotes by the devs showing that they now see GTK+ as GNOME's toolkit first and other desktops are on their own if they don't want to ride along... which explains things like how long it took them to stabilize the GTK+ 3.x theming APIs.)
I still might consider it if the gtk3-mushrooms patchset for making GTK+ 3.x less alien weren't a single-person, amateur effort that's only packaged for Archlinux.
The advantage that Rust's GTK bindings have over Rust's Qt bindings is great enough to counteract any advantage that Qt has over GTK. That's because GTK has an (XML?) schema that allows bindings and documentation to be autogenerated to a large extent. Binding to Qt from Rust is in comparison very difficult (not to mention the fact that Qt's idiosyncratic programming model naturally conflicts with Rust's militant ownership concepts).
Edit: To be clear, I'm not comparing the relative merits of different GUI options, I'm saying that GTK is the only option that you really have in Rust today.
As I mentioned in another comment, I value my GUIs feeling native on my KDE desktop (and not having to reinvent things like QSettings and, last time I tried with GTK+ 2.x, drag-and-drop multi-select for list views) strongly enough that I start with PyQt and then add rust-cpython and Rust if enough of the application can be cleanly encapsulated away from the GUI code to justify the added build-time complexity.
please no one turn this into a gnome 3 flame war. all I wan to know is what HCI flaws did gnome make? it seems fairly universally hated, but unconfigured (fresh rhel or centos install). I like it better than 2.x. I recognize I am unusual in many ways so I wanted to know if maybe I was using 2.x wrong. my workflow on any os is press button start typing the name of an app then hit enter dock to a position on screen then do everything from there. I like it shows what is in the workspace when I got the button. I want to dock apps, move between workspaces and move apps between workspace and start apps only using the keyboard. don't muh care about anything else as long as there is a dark theme. rat poison was a bridge to far for me, but that is the general idea
While I’m always surprised that Gnome seems less powerful and configurable with each release, after installing Dash To Panel it’s mostly tolerable. I too have few needs from a window manager beyond ‘runs emacs’.
Unfortunately, in the GTK+ 3.x era and beyond, the perspective of many KDE users is that hell has frozen over because GTK+ has supplanted MacOS as the GUI with the most alien feel to it.
(Plus, the LXDE developers started a transition to GTK+ 3.x, got fed up, and decided that their upgrade path from GTK+ 2.x would be Qt 5. They then merged with Razor-Qt to form LXQt.)
Personally, what rubs me the wrong way the most is the various ways in which it explicitly goes against what HCI research recommends because the GNOME people just liked it better their way. (And I've read quotes by the devs showing that they now see GTK+ as GNOME's toolkit first and other desktops are on their own if they don't want to ride along... which explains things like how long it took them to stabilize the GTK+ 3.x theming APIs.)
I still might consider it if the gtk3-mushrooms patchset for making GTK+ 3.x less alien weren't a single-person, amateur effort that's only packaged for Archlinux.
(https://github.com/krumelmonster/gtk3-mushrooms)