Enhance: document that build depends on package guile-3.0-dev and texinfo for makeinfo

[bootchk]

Not an issue, just documenting the requirements for building on Ubuntu. It is just a little unusual that the package build-essential (compilers and such) is not enough because the command makeinfo is found in package texinfo.

The context is that I am exploring using Guile and Guile-GI in Gimp. Currently GIMP builds their own TinyScheme interpreter and does not use GI. But the future GIMP v3 strongly advocates using GI for plugins.

[spk121]

@bootchk OK, will do. guile-3.0-dev has to be there because guile-gi needs the #include <libguile.h> file that it provides. No way around that one. I might argue that guile-3.0-dev should be in build-essential.

From reading the old GNU coding standards, it appears that their expectation is that *.info files appear already generated in the release tarballs, so that release tarballs shouldn't need makeinfo. That can be done. Unfortunately, those release tarballs would have to come out of the CI/CD, and not be the ones that github auto-generates from the source tree.

[bootchk]

@spk121 Thanks. Absolutely not a problem.

While I have you (or I can move this question to some other place), the essential thing that the GIMP Guile extension would do is subclass a GIMP class (in Python: class FooClass(Gimp.Plugin): {...} ) and then pass the gtype of that class back into GIMP (again in Python: Gimp.main(FooClass.gtype) ) where Gimp is an introspected object. I am not sure what GIMP does with that, whether it instantiates the class or just calls its methods as class methods. Anyway, the question is: do you have any inkling whether that might work in Guile-GI? It seems rather hairy to me, more of a two-way interaction than I would expect and I am worried that it might be out of scope for Guile-GI. No worries if you just shrug and say "just try it."

[spk121]

Hmm, should be possible, but bootstrapping it might take some figuring out, because you'd have to have gimp launch guile launch guile-gi and then parse the gobject introspection files to get the GType for the gimp class, and at that point get the gimp class. It is hard to know the issues until you get started.

Feel free to open a new issue if you want to talk through it.

[LordYuuma]

W.r.t. your use case, one thing I am somewhat unsure about is whether or not Guile-GI allows you to override methods, which to me knowledge does not appear to be the case. Now certainly within the context of Guile you can define GOOPS methods, that are defined in terms of GI types, but apart from callbacks and closures there's no way of introducing them "back into" GObject. IOW, if you rely on class inheritance from C to do your dispatching, I don't think overriding from Guile works yet.

[bootchk]

Thanks so much. It is all so abstract it makes my brain hurt. I have a reading knowledge of Lisp, I hope you have a reading knowledge of Python. This is the essence of the Python code that I would need to translate into Guile/GOOP/Guile-GI:

import gi
gi.require_version("Gimp", "3.0")
from gi.repository import Gimp

# A plugin must define (but not instantiate) a subclass of Gimp.Plugin, defining concrete methods for virtual methods.
# All methods are invoked (callbacks) from Gimp.

# define a subclass of a Gimp GObject class
class FuPlugin (Gimp.PlugIn):

    ## concrete definition of a GimpPlugIn virtual method ##
    def do_query_procedures(self):
       etcetera

# transfer control to Gimp, expecting callbacks to defined concrete methods
Gimp.main(FuPlugin.__gtype__, sys.argv)

I suppose I should just write a small test case and try it. Write the Gimp side in C/GObject or Python/PyGObject and the other (plugin) side in Guile/GOOP/Guile-GI.

[LordYuuma]

The Guile-GI syntax would roughly be (pardon my indentation mistakes and potential typos)

(use-modules (gi))
(use-typelibs (("Gimp" "3.0") #:prefix 'gimp:))

(set! <FooPlugin> 
  (register-type 
   "FooPlugin"
   gimp:<GimpPlugin>
   #f #f))

(define-method (do-query-procedures (plugin <FooPlugin>)
  ...)

(gimp:main <FooPlugin> (command-line))

However, the do-query-procedures here is bound in Scheme only, and GObject does not know of it. In other words, it won't be able to call it in the way you intend.

For this to work as in Python, we'd have to be able to pass such replacements to register-type, and later actually bind them, e.g. using GOOPS generics.

[spk121]

Moved the discussion about GIMP to #108

The original issue of not describing the build requirements has been fixed by updating README.md