@ebassi

So in the long run until gtk6 all libraries using gobject need to port to gtype?

Haven't counted Christoph's list lazka.github.io/pgi-docs/ but let's say 50-80 libs? That's a lotta work or a lotta stuff left behind. Assuming only the core api.pygobject.gnome.org/ gets preferred treatment.

libraries *today* are using GTypeInstance; and GTK6 is not even on the radar right now. The entire point of this incremental change is to allow to progressively port newly written types and methods to GTypeInstance (which is already supported by bindings, since it's the basis of GObject and it's already used by GTK and other libraries).

I think you're confused because you're not the target audience of the presentation. You may want to read my earlier blog: bassi.io/articles/2023/08/23/t…

The Mirror

This is a rough strawman I put together after various discussions I had during GUADEC 2023 on the future of the GObject type system, introspection, language bindings, and the GNOME application development platform.

^{halting problem}

@ebassi A dense block of info you wrote there :) I knew gobject was some kinda c plus structs and fnctptrs equals cpp plus rtti or vala and more. And it is reasonable to clean up, like the move from x11 geometric primitives to opengl.

I'll try to express my concern more unconfusedly :D
Assuming i write my tinkerer's python like import gi; from gi.repo import xyz;

Which values of xyz will stay :D

bindings will paper over any change when it comes to objects; for the rest: the API will change when it needs to change, just like it happens for every major new version. Some things may even get more Pythonic out of the box.

I don't think you have to worry about anything at the moment: this is an in-progress experiment, and we haven't even started working on GTK5, let alone GTK6. Plus, as I said: language bindings developers are engaged in this effort.