Library for GUI?



To check I just compiled it with 4.05.0+flambda and everything just worked. Including examples.

True, that I have another change in Makefile which changes the target distclean and configure (do no rememember, why I needed them)

--- a/Makefile
+++ b/Makefile
-distclean: clean ocp-distclean
+distclean: clean
+	rm -rf config/autom4te.cache config/config.status config/config.log
+	rm -f config.ocp config/Makefile
 	rm -f ocp-build.root*
+configure: config/ config/m4/*
+	cd config; \
+		aclocal -I m4; \
+		autoconf



so is ocp-build in there and running ok for you?
when I tried compiling it ocp-build proved to be a nightmare and I think it is a dead project now.
so I worked up a makefile to replace it, made some improvements/extensions to the library, and translated the forty thieves demo.

I can scarcely believe you got it compiling!


It worth noting that now lablgtk supports GTK+3, see lablgtk3 branch.


I got the impression glancing at it that it’s somehow doing GTK 2 stuff on top of GTK 3. Is that right?


Probably a stupid question: Could anyone explain why we need bindings to GUI libraries written in other languages and cannot have one written in OCaml?

As I understand it, we technically could write a GUI library in OCaml instead of using bindings, but there wasn’t enough need to put effort in doing so, am I right?

I’m asking because it seems to be limiting to bind to libraries, which are mostly written in an OOP lang with OOP in mind.


Yes, I’ve just checked, and yes

  • ocaml version - 4.07.0
  • ocp-top version - 1.99.19-beta

With the changes mentioned above and some new related to String being immutable

The whole diff agains origin/master is here:


There is one still at very early stages, but promising GUI library, which wasn’t mentioned here.

Maybe, because it is in Reason:


Doesn’t seems so, it supports only these functions that GTK+ 3 has. Just not yet totally complete and well-tested. Hopefully first proper release soon.


It turns out that implementing a large GUI library can take many years of work, so usually people don’t build new ones simply to provide a cleaner native interface for a given language.


Language-built GUIs also tend not to look very good. GUIs need to integrate into a given OS (or in the case of Linux, a desktop environment), and thus need to have special case handling for every OS in order to look like native applications. This is one of the reasons Electron has taken off – the web is now ‘native’ to every OS, and thus applications made using the same ‘GUI’ elements as the browser tend to look like they belong on every OS.


What is your evaluation of only-web-based GUI? (security, usability, etc. )
See other discussions about web vs. desktop GUI.

In which specific cases would you make the choice of a desktop GUI instead? (possibly not looking like the OS GUI)


And it is awful scenario if user has more than one program to run. Good luck running Slack, Nylus, Chrome/Firefox, Visual Studio Code and whatever Electron-based simultaneously on middle-range laptop. Especially if you have more than one site/project opened. Using Qt-based bindings is a way to go (in some cases GTK+ too). Electron is a curse for humanity and it works only in the imagination of developers who think that user going to run only their program and not a hundreds others.


Electron is an amazing way to make an IRC client take gigabytes of RAM. It’s a cool stunt that it works, but it isn’t exactly a boon to mankind.