#gobject — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #gobject, aggregated by home.social.
-
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
-
https://www.europesays.com/uk/745925/ Milky Way’s ‘Central Black Hole’ is Compact Object Composed of Fermionic Dark Matter, Study Says #BlackHole #ColdDarkMatter #DarkMatter #Fermion #FermionicDarkMatter #GObject #Galaxy #MilkyWay #Physics #SStar #S02 #S2 #SagittariusA #Science #Star #SupermassiveBlackHole #UK #UnitedKingdom
-
https://www.europesays.com/ie/322063/ Milky Way’s ‘Central Black Hole’ is Compact Object Composed of Fermionic Dark Matter, Study Says #BlackHole #ColdDarkMatter #DarkMatter #Éire #Fermion #FermionicDarkMatter #GObject #Galaxy #IE #Ireland #MilkyWay #SStar #S02 #S2 #SagittariusA #Science #star #SupermassiveBlackHole
-
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. 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.
-
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. 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. 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.
-
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.
-
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.
-
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.
-
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.
-
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 -
Well, @bugaevc runs very quickly through some very sophisticated implementation details. It probably took months to get right what he references in some seconds…
-
Well, @bugaevc runs very quickly through some very sophisticated implementation details. It probably took months to get right what he references in some seconds…
-
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.
-
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.
-
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).
-
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).
-
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).
-
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…
-
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…
-
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…
-
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…
-
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…
-
#RayLib + #Vala bindings + #OOP #GObject wrapper library written in #Vala = the *best* #gamedev experience of all time!!??
Well, we are working on it! :D At least @halfmexican is one of them!
Check out the vapi and WIP wrapper library, for example look at this beautiful `RaylibOOP.Color` class: https://github.com/Charadon/raylib-vapi/blob/main/src/lib/Color.vala
Also this library can of course be used by *all* other GObject language bindings.
And this sample is just the first, more are coming! For direct updates join our discord server! -
About time to update the shield parsing/rendering to deal with the updated defintions with short-hand "banner maps" from OpenStreetMap Americana.
So, let's dive down into C (pun kinda intended) again… 😁
-
Write your own Wayland Desktop!
The "Astal" framework, which is written in Vala, makes it super-simple! (you can use it with any gobject-introspection language though)
https://aylur.github.io/astal/
Here a WIP project from our community. So far a custom status bar, quick settings, MPRIS, etc. Together with the Hyprland window manager. Built with #GTK4, #Blueprint, #Libadwaita and of course #Vala!
https://github.com/ARKye03/morghulis#GTK #GObject #GObjectIntrospection #Wayland #Hyprland #Astal #freedesktop
