Programming GTK+ programs in C is rather unpleasant in my limited experience.
Despite the set of signals supported by widgets being a fixed part of the documented API, there aren't even explicitly typed-checked function signatures for callbacks appropriate for those signals. The docs tell you what the function signature needs to be for a specific signal like "clicked", but since all the callbacks basically get thrown into a generalized dictionary of void * keyed by signal name hanging off gobject, there's literally ZERO type checking of the callbacks your program installs on signals.
Segfaults because your callback had the wrong parameter types/arity for the signal you connected is the norm, and that's arguably the best scenario. You can also install a callback on a signal that expects a gboolean return, and your callback returns void, welp, no segfault, but unpredictable behavior. It's kind of awful, there won't be any compile-time errors when making these mistakes, despite being C.
It feels like someone learned how to implement a dictionary then made gobject and built a GUI on top of it with dictionaries all the way down. I don't want runtime dictionaries used for representing any set of things known at compile-time. Fine, use dictionaries for runtime-defined signals, but why the hell am I suffering this way for the things fully known by the toolkit before I even started writing my GTK+ program? Sigh. I may as well just write javascript.
Modern versions of GTK+ support Rust, Python and Javascript. I love GNOME, but I think there's a decent group of people that would like a Rust-based GTK+ desktop environment.
This isn't some C problem, this is a GTK+ problem.
There's no need to be throwing all this up-front known crap into a runtime constructed dictionary.
If the widget has a "clicked" signal, there should be a typedef of the callback function appropriate for that signal and the widget struct should have a clicked_cb member for a list of callbacks of that type. Then there should simply be a unique function for installing the callback on that signal on a widget. At least then the compiler can tell you when you're mixing up callbacks<->signals for API-defined signals. It's not even complicated.
The C++, Go, Rust and D bindings already do that, as does Vala, the information is all there to generate the necessary code in a statically typed language. It still wouldn't do anything for you if you want to use a dynamic language or use the xml builder functionality.
Despite the set of signals supported by widgets being a fixed part of the documented API, there aren't even explicitly typed-checked function signatures for callbacks appropriate for those signals. The docs tell you what the function signature needs to be for a specific signal like "clicked", but since all the callbacks basically get thrown into a generalized dictionary of void * keyed by signal name hanging off gobject, there's literally ZERO type checking of the callbacks your program installs on signals.
Segfaults because your callback had the wrong parameter types/arity for the signal you connected is the norm, and that's arguably the best scenario. You can also install a callback on a signal that expects a gboolean return, and your callback returns void, welp, no segfault, but unpredictable behavior. It's kind of awful, there won't be any compile-time errors when making these mistakes, despite being C.
It feels like someone learned how to implement a dictionary then made gobject and built a GUI on top of it with dictionaries all the way down. I don't want runtime dictionaries used for representing any set of things known at compile-time. Fine, use dictionaries for runtime-defined signals, but why the hell am I suffering this way for the things fully known by the toolkit before I even started writing my GTK+ program? Sigh. I may as well just write javascript.