Goals for 0.4

[spk121]

The 0.3.x branch almost worked, but, in practice, it was just too hard to use.

Goals for 0.4

• The guile-gi runtime should not link to GObject/GLib. For those GObject/GLib functions it needs, it must get them at runtime from the libraries that the user is using.
• As a consequence, guile-gi should add a separate parser that converts typelibs into Guile modules, to avoid runtime confusion with libgirepository's GObject/GLib and the user's intended GObject/GLib
• The generated types and functions should be more like the official Gtk docs. The 0.3.x branch tried to make functions look like real Guile, with predicates ('?' '!'), eliding array size arguments, and special INOUT/OUT handling, which seemed like a good idea at the time, but, was a usability nightmare. It is too hard to look at the official Gtk docs and then guess what the Guile type or function should be.
  • The bound types/function naming should prefer GObject conventions to Guile conventions.
  • There was the guile-gi documentation module which answered these questions. In practice, no one used it. No one looks at generated docs. They check the web.
• Unregistered types like structs need to be handled. It isn't possible to do work with only GType classes.
• Make docs web-first. Split docs into separate project. Convert to markdown or whatever.
• CMake or Meson. I prefer CMake, which seems to have the edge for C/C++. Although Meson big with the GNOME people

1. Yeah, @spk121 rejected changes to docs and autotools before. @spk121 felt the need to conform to GNU standards because that is how he was raised. He was wrong and he humbly apologizes. Also, since g-golf is official GNU binding for Guile, guile-gi need not do the GNU.
2. g-golf receives more attention and more daily maintenance. There can be only one; it is okay if it wins. Even so, making guile-gi work is an interesting technical challenge.