#gobject — Public Fediverse posts

I've been playing with PyGObject and it's been a memory management hell. I cannot begin to even fathom how Rust bindings for GObject work. :neodog_googly_shocked:​

#Rust #GObject #PyGObject #FOSS

I've been playing with PyGObject and it's been a memory management hell. I cannot begin to even fathom how Rust bindings for GObject work. :neodog_googly_shocked:​

#Rust #GObject #PyGObject #FOSS

Finally got my YouTube live chat API client library working with the peel C++ bindings generator for #GLib / #GObject. I built a small coroutine task abstraction that makes working with GLib-style async functions much cleaner.

Still a lot more work to do to with caching/refreshing OAuth tokens and processing of messages, but hopefully I can get a prototype libpurple plugin (the ultimate goal) working fairly soon

Nothing to see here, just a MacBook Neo and a GNOME OS laptop talking to each other via the #p2panda #GObject bindings for #Go . They even found each other via mDNS! (Needed a 5 line patch to the Rust build config, but that's it - everything just kind of works!)

Nothing to see here, just a MacBook Neo and a GNOME OS laptop talking to each other via the #p2panda #GObject bindings for #Go . They even found each other via mDNS! (Needed a 5 line patch to the Rust build config, but that's it - everything just kind of works!)

Nothing to see here, just a MacBook Neo and a GNOME OS laptop talking to each other via the #p2panda #GObject bindings for #Go. They even found each other via mDNS!

(Needed a 5 line patch to the Rust build config, but that's it - everything just kind of works!)

Nothing to see here, just a MacBook Neo and a GNOME OS laptop talking to each other via the #p2panda #GObject bindings for #Go. They even found each other via mDNS!

(Needed a 5 line patch to the Rust build config, but that's it - everything just kind of works!)

Let me share some updates about peel 😀

As a reminder, #peel is a project that implements modern :cpp_language: bindings for #GObject libraries, most notably the #GTK stack, and now also #GStreamer.

🧵

Sebastian @slomo has been tirelessly working (and me, helping and reviewing and merging his work) on improving the GStreamer+peel experience, resulting in many improvements all over peel, and also in GStreamer, GLib, and other components of the stack.

Let me share some updates about peel 😀

As a reminder, #peel is a project that implements modern :cpp_language: bindings for #GObject libraries, most notably the #GTK stack, and now also #GStreamer.

🧵

Sebastian @slomo has been tirelessly working (and me, helping and reviewing and merging his work) on improving the GStreamer+peel experience, resulting in many improvements all over peel, and also in GStreamer, GLib, and other components of the stack.

New progress on the #puregotk #GObject introspection things I'm working on in #Go . It's super early, but I added preliminary support for generated getters/setters for properties. No more manual value setup & `SetProperty` calls required, just a simple `SetPropertyX` call.

New progress on the #puregotk #GObject introspection things I'm working on in #Go. It's super early, but I added preliminary support for generated getters/setters for properties. No more manual value setup & `SetProperty` calls required, just a simple `SetPropertyX` call. We're getting closer and closer to more readable code here with this IMHO, GJS on the right for comparison!

New progress on the #puregotk #GObject introspection things I'm working on in #Go. It's super early, but I added preliminary support for generated getters/setters for properties. No more manual value setup & `SetProperty` calls required, just a simple `SetPropertyX` call. We're getting closer and closer to more readable code here with this IMHO, GJS on the right for comparison!

@razze sure, good idea. The general stack is C (but, thankfully #GObject), and with that we also deal with almost All The File Formats (tm) thanks to firmware vendors all doing slightly different thing.

We're slowly migrating bits of the code to Rust, but just don't ask how. We're also bit into fuzzing and testing hundreds of emulated devices in CI. There are quite a few build tools in #python too.

@razze sure, good idea. The general stack is C (but, thankfully #GObject), and with that we also deal with almost All The File Formats (tm) thanks to firmware vendors all doing slightly different thing.

We're slowly migrating bits of the code to Rust, but just don't ask how. We're also bit into fuzzing and testing hundreds of emulated devices in CI. There are quite a few build tools in #python too.

Continued some #GObject subclassing support in Go. Turns out I messed up the C memory alignment in #Go for and ended up embedding the parent class as a reference, when GObject expects it to be the actual struct.

Continued some #GObject subclassing support in Go. Turns out I messed up the C memory alignment in #Go for and ended up embedding the parent class as a reference, when GObject expects it to be the actual struct.

Continued some #GObject subclassing support in Go. Turns out I messed up the C memory alignment in #Go for and ended up embedding the parent class as a reference, when GObject expects it to be the actual struct. Funnily enough some callbacks still worked before this, but now even the ones like `Snapshot` and `Activate` work. To demonstrate, here is a Go application subclassing AdwApplication and overwriting the `activate` callback instead of calling `ConnectCallback`!

Continued some #GObject subclassing support in Go. Turns out I messed up the C memory alignment in #Go for and ended up embedding the parent class as a reference, when GObject expects it to be the actual struct. Funnily enough some callbacks still worked before this, but now even the ones like `Snapshot` and `Activate` work. To demonstrate, here is a Go application subclassing AdwApplication and overwriting the `activate` callback instead of calling `ConnectCallback`!

Now that my PRs for #GObject subclassing support in Go are up on GitHub and ready for review, I can get started porting over Sessions to Gsk instead of Cairo.

Now that my PRs for #GObject subclassing support in Go are up on GitHub and ready for review, I can get started porting over Sessions to GSK instead of Cairo. It was easier to do find examples in JS, so that's what I used, but next up is getting this to work with the freshly implemented `snapshot` function override!

Now that my PRs for #GObject subclassing support in Go are up on GitHub and ready for review, I can get started porting over Sessions to GSK instead of Cairo. It was easier to do find examples in JS, so that's what I used, but next up is getting this to work with the freshly implemented `snapshot` function override!

May I present: Typed subclassing of #GObject classes in Golang! Still a WIP, but this is enough now to create proper custom #GTK widgets in #Golang without needing to import any `purego`/CGo code to subclass.

May I present: Typed subclassing of #GObject classes in Golang! Still a WIP, but this is enough now to create proper custom #GTK widgets in #Golang without needing to import any `purego`/CGo code to subclass. Please ignore the `Constructed` callback call here, it's just there to test if getting a callback (e.g. a constructor works), too. 🥳

May I present: Typed subclassing of #GObject classes in Golang! Still a WIP, but this is enough now to create proper custom #GTK widgets in #Golang without needing to import any `purego`/CGo code to subclass. Please ignore the `Constructed` callback call here, it's just there to test if getting a callback (e.g. a constructor works), too. 🥳

First a bit of context for the GLib project, which is comprised of three main parts: GLib, GObject and GIO. #GLib contains things you'd generally get from a standard library, #GObject defines the OOP semantics (methods/properties/signals, inheritance, etc), and #GIO provides reasonably high-level APIs for everything from sockets and files to D-Bus and Gio.DesktopAppInfo.

https://andyholmes.ca/posts/best-intentions/

First a bit of context for the GLib project, which is comprised of three main parts: GLib, GObject and GIO. #GLib contains things you'd generally get from a standard library, #GObject defines the OOP semantics (methods/properties/signals, inheritance, etc), and #GIO provides reasonably high-level APIs for everything from sockets and files to D-Bus and Gio.DesktopAppInfo.

https://andyholmes.ca/posts/best-intentions/

iunno why, but programming with #glib / #gobject just feels a lot more fun than wrestling with c++

which is kinda weird, you'd think that a language specifically built for OOP would be better at it than trying to replicate it with a C library

iunno why, but programming with #glib / #gobject just feels a lot more fun than wrestling with c++

which is kinda weird, you'd think that a language specifically built for OOP would be better at it than trying to replicate it with a C library

Just got GTK #GObject subclassing to work in #Go thanks to some new bindings by https://github.com/jwijenbergh 👀

Just got GTK #GObject subclassing to work in #Go thanks to some new bindings by https://github.com/jwijenbergh 👀

🚀 Wow, rewriting #Ghostty with #Zig and #GObject is like knitting a sweater with spaghetti - impressive, but why? 🤔 Meanwhile, using #Valgrind to verify memory is just a fancy way of saying "I found #bugs in my own code, again." 🍝💻
https://mitchellh.com/writing/ghostty-gtk-rewrite #programming #HackerNews #ngated

🚀 Wow, rewriting #Ghostty with #Zig and #GObject is like knitting a sweater with spaghetti - impressive, but why? 🤔 Meanwhile, using #Valgrind to verify memory is just a fancy way of saying "I found #bugs in my own code, again." 🍝💻
https://mitchellh.com/writing/ghostty-gtk-rewrite #programming #HackerNews #ngated

Well, @bugaevc runs very quickly through some very sophisticated implementation details. It probably took months to get right what he references in some seconds…

#GObject #bindings #guadec2025 #peel #Cplusplus

Well, @bugaevc runs very quickly through some very sophisticated implementation details. It probably took months to get right what he references in some seconds…

#GObject #bindings #guadec2025 #peel #Cplusplus

Like the way @bugaevc starts with presenting GTK C boilerplate for setting a property. It really *IS* a reason for new developers not to use #GTK at all.

#gobject #peel

Like the way @bugaevc starts with presenting GTK C boilerplate for setting a property. It really *IS* a reason for new developers not to use #GTK at all.

#gobject #peel

Folks, I can definitely recommend this talk from @bugaevc at #guadec2025!

https://floss.social/@gnome/114873444742029431

Sergey has been of great help for my minor stumblings of trying to write #ObjC #GTK bindings for #ObjFW. He's got formidable knowledge und deep insight into #GObject especially and Cxx languages in general.

Folks, I can definitely recommend this talk from @bugaevc at #guadec2025!

https://floss.social/@gnome/114873444742029431

Sergey has been of great help for my minor stumblings of trying to write #ObjC #GTK bindings for #ObjFW. He's got formidable knowledge und deep insight into #GObject especially and Cxx languages in general.

🔧 "Bridging type systems"
with Sergey Bugaev at #GUADEC2025
📅 25 July 🕒 09:00 CEST 📍 Brescia

💡 Sergey introduces peel, a fresh take on C++ bindings for GObject: zero overhead, full API coverage, deep type support.

🔗 https://events.gnome.org/event/259/contributions/1225/

#GNOME #CPlusPlus #GObject #Bindings #GTK

🔧 "Bridging type systems"
with Sergey Bugaev at #GUADEC2025
📅 25 July 🕒 09:00 CEST 📍 Brescia

💡 Sergey introduces peel, a fresh take on C++ bindings for GObject: zero overhead, full API coverage, deep type support.

🔗 https://events.gnome.org/event/259/contributions/1225/

#GNOME #CPlusPlus #GObject #Bindings #GTK

What kind of worries me is the observation that many #GObject / #GNOME projects are in a somewhat abondoned state since the overwhelming use of mobile apps and web services around 2012 to 2014. There are some great exemptions like the #Evolution support by #RedHat and all the tools by @linuxmint.

Same is to apply to the #ObjC ecosystem which has seen few new projects since 2015 or so.

#ecosystem

What kind of worries me is the observation that many #GObject / #GNOME projects are in a somewhat abondoned state since the overwhelming use of mobile apps and web services around 2012 to 2014. There are some great exemptions like the #Evolution support by #RedHat and all the tools by @linuxmint.

Same is to apply to the #ObjC ecosystem which has seen few new projects since 2015 or so.

#ecosystem

So the conclusion is: If I want to improve what I'm using, I need to get my hands dirty and learn to write and fix that kind of software written in #GObject #C.

I'm happy there is @objfw as well which makes facing C less of a pain.

#ObjGTK probably will never be "finished", but it already helps using #GTK without me needing to learn #Rust, which I won't be able to achieve in my spare hours.

So the conclusion is: If I want to improve what I'm using, I need to get my hands dirty and learn to write and fix that kind of software written in #GObject #C.

I'm happy there is @objfw as well which makes facing C less of a pain.

#ObjGTK probably will never be "finished", but it already helps using #GTK without me needing to learn #Rust, which I won't be able to achieve in my spare hours.

It's not that I'm a great fan of the #GObject type system and its way to build object-oriented code in C. I know some of the maintainers aren't as well, which I don't consider a surprise given the age and origin of that GObject ecosystem. So I absolutely understand #Canonical considered switching to #Qt for #Unity8, now #Lomiri.

But that's only one part of the story. The other part is I'm now using #GTK based desktop environments almost full time (only some occasions I turn on my old Mac).

It's not that I'm a great fan of the #GObject type system and its way to build object-oriented code in C. I know some of the maintainers aren't as well, which I don't consider a surprise given the age and origin of that GObject ecosystem. So I absolutely understand #Canonical considered switching to #Qt for #Unity8, now #Lomiri.

But that's only one part of the story. The other part is I'm now using #GTK based desktop environments almost full time (only some occasions I turn on my old Mac).

okay, i think i don't entirely understand when i should claim a reference using g_object_ref and when i shouldn't #GLib #GObject

question 1: should a function that returns a pointer to an object g_object_ref it for the caller's sake?

okay, i think i don't entirely understand when i should claim a reference using g_object_ref and when i shouldn't #GLib #GObject

question 1: should a function that returns a pointer to an object g_object_ref it for the caller's sake?

I have not blogged or talked about the follow-up work to my "GType Next" blog post that I've been doing in my spare time, mainly because it is happening *in my spare time*, and I don't want to give false impressions to people; the other reason is that the time consuming bit is not writing a bunch of code, but it's planning ahead, because the goal is to avoid breaking stuff at all costs…

#glib #gobject #gtk