Library for GUI?

Community
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.

1 Like
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

5 Likes
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.

3 Likes
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.

4 Likes
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.

7 Likes
34

@jamie I want to do it. I’m wrapping up a new version of Logarion and then starting it.

(I’ve also promised to tidy up some OCaml-QML bindings I’ve worked on)

I’d not be sharing this until there was something tangible, but I don’t want the hope to die :slight_smile:

1 Like
35

It worth noting that OniVim (Electron-based GUI for Neovim) recently decided to switch to the native GUI, creating Oni2 project

They use Revery UI platform for Reason language.

1 Like
36

I always thought that Electron is heavy because it has HTML engine inside it. Looking to the Revery README it seems that it will have the same issue too. Why Revery will be better?

1 Like
37

Revery doesn’t have any HTML rendering engine. Everything is compiled with ocamlopt and render with OpenGL/WebGL

3 Likes
38

Ah, thanks! I have seem react-like core in the readme, so I decided that HTML is somehow used there too.

P.S. Can somebody explain why the folks are inventing the wheel with new OpenGL GUI library instead of using Qt/Qml?

P.P.S. I got a crazy idea. It would be great to transpile ReasonML syntax to Qt/Qml to reuse existing components. Reactive programming will work out of box, we will get rid of untyped javascript in Qt/Qml. Obviously it will be adopted only if folks afraid only about untyped nature of javascript in Qt|Qml

39

With lablgtk and lwt_glib, i can do asynchronous applications. Is it possible with Qt/Qml or revery?

1 Like
40

Integrating with an async framework (Lwt/Async) is being worked on. But from the architecture point of view, nothing prevent you from doing so. This model have been proven in React.js framework.

At the heart, there is a reconciler called brisk-reconciler. It takes the JSX which is desugars into a bunch of nested function calls + the current state of the world and returns a set of updates to a tree.

The renderer (revery) would render this into OpenGL scenes. Or brisk would render this into native components.

The asynchronous problem is totally separated from the framework. It just needs proper integration

4 Likes