And yet C++ so clearly had useful language features like closures and smart pointers and class syntax that could be used to significantly clean up the C GObject code.
So I had these various ideas about how it could be possible to do things better in various aspects compared to gtkmm, to make use of C++ language features while not introducing any limitations or runtime overhead.
Perhaps we could do custom classes like this. Perhaps something like this could be done for signals. Perhaps we could have a RefPtr that actually managed GObject reference count.
But these ideas, they were largely theoretical (I'd spend some time prototyping them in Godbolt at best), and while they were covering various aspects, they were not connected to one another, they were just bits and pieces, and a larger picture was missing.
It took a lot of design work to combine them into one cohesive vision, and to actually implement things, and make them work good enough in practice, to the point where peel could actually supplant gtkmm.
But this now exists and works, and it turned out better than I could dream of.
It felt truly magical the first time that enough pieces had fit together and you could write a C++ program that looked very much like code using gtkmm, but it was peel underneath, and it compiled and worked.
When hacking on peel internals, it often feels like just some smoke and mirrors, just a bunch of reinterpret_casts<>'s in a trenchcoat, spit out by a Python script. Like there's no actual bindings, it's all cheating.
But then you write a program as a user, and it comes alive. The classes and the methods are there. You can use them (without thinking too hard what's inside), and they work. And then you build with -O3 and disassemble, and it looks just as if you wrote it in plain C.
Magic ✨. Carefully engineered magic.
A space for Bonfire maintainers and contributors to communicate
