Automatic generation of lablgtk bindings

sacerdot commented 4 years ago

Hi everybody,

lablgtk bindings are (mostly) hand-written. The Haskell guys instead made a much better job, automatically generating their bindings from GI (GObject Introspection). I have assigned to a master student of mine the task of trying to adapt the Haskell code to spit-out "lablgtk"-like bindings.

The student worked extremely well and there is now a working prototype at: https://github.com/illbexyz/ocaml-gi-gtk

The prototype is not fully completed: some ad-hoc Gtk types (eg. GArrays) still need some code. However it can already generate twice the number of methods of the current bindings and it should work on any GI library. I have tried a few examples and they work.

The student has now ended his master period and I need to decide if investing more resources on the project or not. Here I list some pros&cons of automatic generation:

PROS

full coverage of Gtk libs and additional GI libs
code better aligned to the C API (easier to understand the doc)
"front-end" code, i.e. the code to parse the GI format, shared with the Haskell community and thus better maintained

CONS

dependency on Haskell code; it could be removed by porting all the generation code to OCaml
no more ad-hoc stuff: for example some methods now have labels, but not in a systematic way; a lot of other small changes here and there exist now to provide a more camlish API and they would disappear
need to port (again) all existing code (Coq, etc.) to the new API. The student tried to stay as close as possible to current lablgtk, but some changes here and there must be applied (e.g. right now the mapping from widgets to files is arbitrary, e.g. some in GMisc, etc.)

What are your opinions?

Cheers, C.S.C.

ejgallego commented 4 years ago

It seems very cool to me; I am not expert on this kind of stuff but certainly it would greatly help in finish the porting to some new libs such as sourceview4.

sacerdot commented 4 years ago

Great. I am slowly porting the various examples and applications to iron out bugs/discrepancies and to reduce the manually generated code base. It is not ready yet for prime time.

The only thing that is a bit annoying w.r.t. lablgtk3 is lack of labels and default values for method arguments. Labels are easy to add, maybe only when two parameters have the same type. But there is no way to have reasonable default values for optional parameters because the info is not in GIR (despite many implementors of bindings voicing for them).

As soon as it is reasonably stable I will ask for help. In particular it would be cool to try to port some large application (Matita and Coq for example).

@garrigue: do you have any comment?

ghost commented 3 years ago

Would be great, lablgtk3 lacks GtkHeaderBar, DrawingArea had it signals number reduced between gtk2 and gtk3, ... lots of small changes.

garrigue / lablgtk

Automatic generation of lablgtk bindings #106