Re: GNU G-Golf 0.8.0-rc-3 available for testing

["pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>]

Hello David,

David Pirotte <david@altosw.be> writes:
> fwiw, g-golf doesn't load/import/invoke/call nor the GdkPixbuf
> typelib, nor any of its functions/methods 'on its own', nor
> does any example, this occurs as part of the Gtk/Gdk/Gsk
> 'engine' - it is not g-golf that 'runs g_typelib_symbol on
> GdkPixbuf functions;

I had not known that g-golf does not call g_typelib_symbol.  I will
have to read more what calls it initially.

The initial calls are to a GdkPixbuf path listed in environment
variables, later calls are to a GdkPixbuf path referenced in the files
that are part of GTK.  Yes, Guix should make it so the two are the same.

> Fwiw, debian 'generally' has two pkg for 'those situations', one with
> the library itself and one for the debug symbols:

Guix does the same, but for GTK, it runs a different GdkPixbuf build
entirely without debug symbols, with different build steps, therefore a
different hash, therefore a different file path.  Guix has bug#48907
filed, because debug symbols do not work, that Guix should not create
two paths or that debug symbols should work despite Guix doing that.

> You (the guix team) should fix Guix, not the g-golf app(s).

Yes.

>> The second issue is the vfuncs when running
>> examples/gtk-4/drawing-widget.scm.  This segfaults at
>> gtk_widget_snapshot_child when run.

This I will investigate firdy.

> […]
> What about pygobject?

pygobject GTK3 examples are working.  I will experiment and try to write
Vala/C code that breaks now.

> 1-	fix guix to have one gdk-pixbuf module
> 2-	let's try to fix the vfunc problem in guix, using the
> 	examples/gtk-4/drawing-widget.scm ... or some even easier vfunc
> 	test code i could write if necessary

I will look at 2 in the next days.

Regards,
Florian