GIR gobject introspection GItypelib unloading

When I use

https://developer.gnome.org/gi/stable/GIRepository.html#g-irepository-require

to load the Typelib for binding creation for a compiled language, that function refuses to load another version of typelib. So it is difficult to create bindings for GTK3 and GTK4 at the same time.

First I thought that i missed something, but from this 8 years old issue it may be really not possible:

https://gitlab.gnome.org/GNOME/gobject-introspection/issues/46

Or is there a trick available?

I think when my program terminates, the typelib is unloaded automatically. So I may have to launch my generator program two times – makes thinks not really easier.

But the good news is: We will have Nim GTK4 bindings soon!

You cannot load GTK 3 and 4 (or 2 and 3, or 2 and 4) at the same time. Symbols will conflict, and types will be registered twice—GTK 3 has a GtkWidget type, just like GTK 4 does.

Yes, symbols are unloaded alongside the rest of the memory, when the process terminates.

Well, my wordings may be not fully accurate…

I wanted to launch my generator program only once, to generate all the Nim binding files. That includes the basic common set like glib, pango and the new split once like gtk4, gtk3, gdk3, gdk4 …

Of course a Nim user has to decide then if he wants to import gtk4 or gtk3, he can not import both, they would conflict.

But ok, so I have to rewrite my generator a bit so that I can launch it too times in sequence.

Why? If you do that, you cannot parallelise the code generation, for instance.

I mean: you can’t unload typelibs, so you can’t really do that anyway. You can only load the target typelib (and its dependencies), generate the output, and terminate.

Why? If you do that, you cannot parallelise the code generation, for instance.

Well, currently some global information is collected in the gtk.nim file. That information includes all the signal names available for g_signal_connect(), and a check for possible symbol name conflicts. (For Nim we generally remove function name prefixes like gtk_, so rare conflicts can occur.) Before yesterday our binding generator worked only for gtk3. Yesterday I installed gtk4 on /opt/gtk and launced gtk4-demo successfully. So I considered patching the Nim bindings generator to work with gtk4. Was only a few hours of work. I can already create simple gtk4 apps with Nim. But now I have to make the generator work for gtk3 and gtk4 at the same time. I do not want to split it in two separate packages. I may add an option that user can select during install if he wants only one of both versions, only gtk4 or gtk3. But I think users will generally want to have both when available, so I think I will not create an option. I will simple try to create the gtk3 files, and then relaunch and try to generate the gtk4 files. Both have the common binding set like pango, glib an such. I really think and hope that the same binding file for glib or pango can be used with gtk3 and gtk4. At least on my box that works. What I do not know currently is if your graphene can be used with gtk3.

Of course we may rewrite the whole bindings generator eventually…

And what really is a bit strange: GtkSourceView4 seems not to be usable with GTK4. Not tested, but I read it in D-lang forum.

GTK3 does not depend on Graphene.

The “4” is not related to GTK4; GtkSourceView has its own API version.

Of course not. We all used gtk3 since many years without graphene. I was only wondering if a gtk3 app may be able to use graphene.

Why wouldn’t it? Graphene doesn’t do anything with GTK, it’s just a bunch of vector code.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.