Library for GUI?

gui

#21

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/configure.ac config/m4/*
+	cd config; \
+		aclocal -I m4; \
+		autoconf
+

#22

vrotaru

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!


#23

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


#24

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


#25

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.


#26

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: https://gist.github.com/vrotaru/f10f1ef272652ed8c321de761b34a245


#27

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

Maybe, because it is in Reason: https://github.com/bryphe/revery


#28

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.


#29

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.


#30

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.


#31

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)


#32

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.


#33

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.