Library for GUI?

As @thangngoc89 said, nothing prevent you doing that from architecture point of view. I tried some demos where GUI in QtQml and OCaml are separated to different threads, they are able to communicate. To be more precise you can implement any concurrency API in any language and expose it to Qt/QML side as your functions.
But for simple things the XMLHttpRequest is built in.

The more I think about Revery, the more I like it. What’s a good path for an OCaml programmer to get started on this?

2 Likes

I’m pretty excited by it, too. I haven’t been able to get it building on my Mac so far, not sure why. One problem I’ve had is that currently you need to use esy to build, not just opam.

Maybe it would be good to have a new thread for Revery so it doesn’t get buried in a general GUI thread?

1 Like

Currently, esy is a requirement because the libraries to built it wasn’t published anywhere (not npm, not opam)

In the last few years I have been developing a GUI for (and in) ocaml, as a hobby project.
Finally, I have made the current state of this thing (called “bogue”) available on github, see

https://github.com/sanette/bogue

Just in case some of you are interested in having a look.
Comments welcome, of course.

11 Likes

Is “bogue” in opam? It would be interesting to try it…

not yet, but this is the plan. I still have to figure out how to do this. It should be easy, since locally, I already have an opam package on my computer.
Yesterday I tried the ‘opam publish’ script, but it fails with
[ERROR] Uncaught exception: “/usr/bin/git fetch --multiple origin user” exited with code 128
I guess I’ll have to do it manually. Any help welcome.

You might want to ask for help with the packaging in a distinct discuss thread.

1 Like

I just made a video to show some of bogue’s features:

7 Likes

I am currently working on developing the 7GUIs in Bogue. It’s been interesting so far.

5 Likes

A self-contained GUI library is relatively straightforward to write in OCaml and a joy to use compared to conventional solutions. I did this ~20 years ago using OpenGL via LablGL and the main challenges I encountered were:

  • Clipboard interop.
  • Idiomatic Load/save dialog boxes.
  • Fragility of binaries generated by OCaml.
  • Immaturity of LablGL at the time.

However, whenever I need a GUI today I reach for web-based stuff and not native WIMP GUIs.

I think all the things you mention are good reasons to go for mature GUI toolkits. Plus a native look is nice. Personally, I don’t like the complexity and massive memory consumption of having to go web-based if I don’t have to. The web reinvented gui from scratch, and getting something simple up and running can be a pain compared to a mature gui, not to mention interop with C-based libraries.

2 Likes

If we’re talking about Electron, ok.

But I believe an option these days is to rely on the Webview2 library which comes with Windows 11.

I remember testing this golang solution 2 years ago: Introduction | Wails

And the memory consumption was roughly 10 times less than Electron. I don’t remember how other OSes were handled but I remember observing that memory consumption was pretty good comparatively.

Not my domain of expertise though

Along the lines of wails et. al, there is a new kid on the block - socketsupply’s socket (https://socketsupply.co/).

So that’s a good point – I guess they’ve really managed to make this stuff more lightweight.
Personally, I’m not interested in the awkwardness that is web development. Traditional GUIs work just fine, and are generally easier to use from my experience. It’s probably not how I would ship a full-blown application, but for internal tooling, a script wrapper, or a hobby project, I’m much happier adding a few lines of code to my program and getting a fully functional gui. I agree though that this has been displaced as the ‘professional’ option these days, and a company simply cannot get away with shipping something that doesn’t look well-designed and webby anymore.

1 Like

The Web approach is interesting when we have a common database shared by many users. We need to have the database schema updated synchronously with the clients. If all is in the server, upgrades are made easier.

With Ocsigen, we have a simplified way to share computing between the server and the client. A desktop application can however use RPC functions (RPC (Remote Procedure Calls) | OCamlverse) and ease the client-server interaction.

Web application are also easier to deploy on PC/Mac/iOS/Android…

But many applications are also desktop oriented…

1 Like