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

[David Pirotte <david@altosw.be>]

[-- Attachment #1: Type: text/plain, Size: 5729 bytes --]

Hello Florian,

> To develop with G-golf and GTK as in G-Golf’
> examples/adw-1/hello-world.scm or examples/gtk-4/hello-world.scm, the
> Guix commands must (at the time of writing) be used with the
> “--no-grafts” option, because G-Golf first when loading runs
> g_typelib_symbol on GdkPixbuf functions from Guix’ normal gdk-pixbuf
> package, but later when it presents the GTK window, GTK tries to load
> GdkPixbuf functions from a mostly identical replacement gdk-pixbuf
> package ...

Wow :) - A bit scary!

	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;

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

	david@... ~ 1 $ lpkg gdk-pixbuf
        ii  libgdk-pixbuf-2.0-0:amd64                                2.42.10+dfsg-3+b3                        amd64        GDK Pixbuf library
        ii  libgdk-pixbuf-2.0-0-dbgsym:amd64                         2.42.10+dfsg-3+b3                        amd64        debug symbols for libgdk-pixbuf-2.0-0
        ii  libgdk-pixbuf-2.0-dev:amd64                              2.42.10+dfsg-3+b3                        amd64        GDK Pixbuf library (development files)
        ii  libgdk-pixbuf-xlib-2.0-0:amd64                           2.40.2-3+b2                              amd64        GDK Pixbuf library (deprecated Xlib integration)
        ii  libgdk-pixbuf-xlib-2.0-dev:amd64                         2.40.2-3+b2                              amd64        GDK Pixbuf library (development files)
        ii  libgdk-pixbuf2.0-0:amd64                                 2.40.2-3+b2                              amd64        GDK Pixbuf library (transitional package)
        ii  libgdk-pixbuf2.0-bin                                     2.42.10+dfsg-3+b3                        amd64        GDK Pixbuf library (thumbnailer)
        ii  libgdk-pixbuf2.0-common                                  2.42.10+dfsg-3                           all          GDK Pixbuf library - data files
        ii  libgdk-pixbuf2.0-dev:amd64                               2.40.2-3+b2                              amd64        GDK Pixbuf library (transitional development files)
        ii  libgdk-pixbuf2.0-doc         

	[ did paste the all list of *gdk-pixbuf* pkgs just in case, but
	[ i was refering to the two first listed pkgs in my comment ofc ...

> If a G-Golf using GTK app were to be packaged for Guix, the package
> would have to use tricks to reference GTK’s gdk-pixbuf package and not
> normal gdk-pixbuf.  (Guix only has one G-Golf app packaged currently,
> the nomad web browser, which is broken in current Guix.)

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

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

But why (does it works fine on debian (and other distros) and fails on
guix (it fails on homebrew as well, fwiw)), is the question - Again,
g-golf doesn't call gtk_widget_snapshot_child 'on its own', this occurs
as part of the upstream [Gsk] snapshot implementation ... so this
particular method is called by the gobject/gtk[gsk actually] engine,
not g-golf - g-golf 'merely' installs the snapshot closure pointer in the
derived class it defines.

>  Similarly examples/gtk-4/peg-solitaire.scm segfaults at
> gtk_image_set_from_paintable called from g_callable_info_invoke.

It probably is a different bug, the peg-solitaire does call set-from-paintable,
we can(should) probably separate this from the vfunc related bug,
though the peg-solitare also define vfunc (it has to ...)

> segfaults at least with guile and guile-next Guile versions 3.0.9 and
> 3.0.9-0.db7efa5.

this has nothing to do with guile - fwiw, it should even work with
guile 2.0.14

>  I do not understand the cause or the vfunc implementation in
> G-Golf’s g-golf/hl-api/vfunc.scm file.

Please read the doc, follow the upstream link(s) proposed, and let me
know if there is still something you do not understand after done so:

	https://www.gnu.org/software/g-golf/manual/html_node/VFunc-Alley.html
	
> I will try to compare it with Vala-generated C code and try to make
> it fail similarly.

What about pygobject? Not familiar with Vala, but i am familiar with
some of the pygobject code, and if necessary, i can ask for some help in
#introspection (on matrix, not irc anymore).

> examples/gtk-4/simple-paintable.scm fails at (add-to-load-path
> (dirname (current-filename)).  I have not yet spent time to debug
> this one further.

It needs to do so to in order to import the (nuclear-icon) module,
which sits next to ... but that module calls define-vfunc, so we should
first and above all fix the define-vfunc problem in guix, and for this
we should use the examples/gtk-4/drawing-widget.scm, which is 'dead
simple'.

> I have not run adw1-demo.scm successfully, because the modules it
> needs are not in the load path.  I guess this is the same small issue.

Definitely, it needs to find all its modules ... i wonder why (dirname
(current-filename)) works for debian and fails for guix (?) - Any other
projects ever report this?

In conclusion, my recommendations:

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

Thanks,
David






[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]