Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic generation of lablgtk bindings #106

Open
sacerdot opened this issue Feb 12, 2020 · 2 comments
Open

Automatic generation of lablgtk bindings #106

sacerdot opened this issue Feb 12, 2020 · 2 comments

Comments

@sacerdot
Copy link
Collaborator

@sacerdot sacerdot commented Feb 12, 2020

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

This comment has been minimized.

Copy link
Collaborator

@ejgallego ejgallego commented Feb 12, 2020

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

This comment has been minimized.

Copy link
Collaborator Author

@sacerdot sacerdot commented Feb 18, 2020

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.