I decided to share some of the adventures I had with gtk4. I won't pretend I like gtk, but the main point is not gtk-bashing. Not even helping others convert their code to gtk4 (the gtk project has fine documentation for that).
The point is pondering some of the design decisions they made, trying to understand the consequences and alternatives.
It's also important to note that librnd (and pcb-rnd and Ringdove) is not a typical user for gtk4: I am not developing a "native gtk4 application", not trying to "be part of the gnome desktop". Instead, for librnd gtk4 is just one of the many parallel GUI backends.
One of the major consequences of that fact is that librnd always builds dynamic GUIs. Widgets are always created from code, run-time, and they may differ from execution to execution.
This also means that Ringdove and librnd regards gtk4 as a "library for drawing buttons", while gtk is probably more intended to be a full featured graphical environment for a gnome application.
Each rant will go in a separate pool node. Another purpose of such a rant is documenting the reasons for unusual decisions in our gtk4 HID code.
Their support is excellent on irc.gnome.org/#gtk4. There are almost 24/7 coverage by gtk developers who are quick and helpful to answer questions and provide support to newbies.
Gtk is implemented in C. More precisely it's C99. There is an usable C API. This makes gtk unique in its league: other big "modern toolkit libs" are C++ or worse.
Unlike qt with qmake, gtk does not force its idea/preference of how the code should be built on the application project. In case of huge libraries that are unfortunately more like "programming environments" than utility libraries, this is also becoming a rare bonus.
Gtk depends heavily on glib, which brings all the OOP overhead you didn't want to have when you decided to choose C and not C++ for your project. There is a separate rant on this topic..
The build deps for gtk is extensive. Instead of plain old make, it unfortunately uses meson. Plus a standard Debian build depends on multiple hundred megabytes of unreasonable junk: dbus, cups, json, sassc, python3, libgstreamer (yes, a media streamer!), librsvg...
The code is unfortunately kept in git and with the whole "collaborative framework" built around it using gitlab. This means you can't easily report bugs without using javascript and registering to yet another web2.0 thing.
The code is huge. I mean HUGE. Libgtk 4.4.1 itself is about 2.7 million sloc. This doesn't include glib (809k sloc), libpango (55k sloc), libepoxy (61k sloc), libgraphene (18k sloc). So dependencies that are very closely coupled with gtk and are likely not needed by other parts of the application only by gtk take another 0.9 million sloc.
Note: gtk2 was a "mere" 582k sloc, so gtk core part alone grew almost five times bigger between gtk2 and gtk4, and mandatory dependencies grew a lot too.
The API documentation is sparse and doxygenish: often a lot of noise repeating trivial things that anyone would see just by looking at a function declaration in code, while important questions we want documentation for unanswered.