Post AwUMJQrH5ixVIALWAS by bugaevc@floss.social
(DIR) More posts by bugaevc@floss.social
(DIR) Post #AwUMJNarEJ2nANdrf6 by bugaevc@floss.social
2025-07-25T10:07:05Z
0 likes, 0 repeats
peel was born out of my frustration trying to write idiomatic :gtk: in gtkmm.I felt that, while gtkmm was indeed letting me use GTK in a way that felt very C++'y, it was severely limiting what I could do, and was making my widgets feel extremely third-class, compared to the C-written ones in GTK proper — I went into some more details about this in the talk.
(DIR) Post #AwUMJPMkdiwsfD3cx6 by bugaevc@floss.social
2025-07-25T10:07:42Z
0 likes, 0 repeats
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.
(DIR) Post #AwUMJQG3K7BVQivn9M by bugaevc@floss.social
2025-07-25T10:09:04Z
0 likes, 0 repeats
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.
(DIR) Post #AwUMJQrH5ixVIALWAS by bugaevc@floss.social
2025-07-25T10:10:31Z
1 likes, 0 repeats
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.