[ANN] OCaml-stk 0.2.0 and Chamo 4.1.0

Community
1

Hello,

Stk

A new release of OCaml-stk, 0.2.0, is now available in opam (package stk).

OCaml-stk is a Graphical User Interface library based on on libSDL 2, through the Tsdl bindings.

As the library is under heavy development, this release includes many changes: new widgets, better memory management, css-like theming, …

By cloning the repository and running make, you can then run ./_build/default/examples/examples.exe. This example application contains demonstrations of each widget with the corresponding code in the same window.

Chamo

A new release of Chamo, 4.1.0, is also available in opam (package chamo).

Chamo is a source code editor, even if it can be used to edit any text file. It is based on OCaml-stk. This release contains small bug fixes and follows changes in OCaml-stk.

8 Likes
2

Chamo appears to be text-only? I wonder, what ambitions does it have? To become a powerful extensible tool like Emacs? To work within a GUI? Emacs has too much age and luggage that make all-too-many things brittle, even to seasoned lispers.

3

“Ambition” would be quite a big word. t’s just my personal code editor, which can be extended with OCaml code. A system of ‘views’ allows different types of document to be opened; although the main view is a code editor with syntax highlighting, I can also open a browser developed in ocaml (not yet distributed). It would be easy to add specialized views for other types of files, using appropriate widgets.

4

I’m in search of alternative to Emacs. Currently, it’s a decent pragmatic solution that is held afloat by the availability of massive code base. However, it’s over-scripted to the point of becoming an “Emacs OS”, and that OS has very limited foundation.

5

What are the key features you want ? There are already alternatives for ocaml code edition (and I’m sure everyone here have an opinion or advices on this point).

Chamo could have more specific features, it would “only” require some developments to create additional “views” or add more edition features to the existing text view.

6

Regarding Stk, I just added a general introduction and a (still incomplete) gallery.

2 Likes
7

Does Stk have a hard dependence on Lwt? I try to use Async everywhere…

Also, may I inquire, why did you choose to use SDL, and not e.g. just directly interface with OpenGL?

8

Does Stk have a hard dependence on Lwt? I try to use Async everywhere…

Not that much but I would not like to have to functorize all modules.

Also, may I inquire, why did you choose to use SDL, and not e.g. just directly interface with OpenGL?

I always associated OpenGL to intensive graphics computations and already experienced some problems with opengl applications not running because of drivers problem. SDL seemed stable enough with good bindings provided by Daniel Bünzli so I gave it a try. What interested me in the first place was to design the toolkit in OCaml to offer a nicer interface and do not have to follow always-changing interface like gtk.

What I miss with SDL is better integration with environment (I can handle drop, but not drag to other applications) and ability to forward display, like it is possible with Xlib. I may consider switching to Xlib in the future, if good bindings are available, but I think the general design and API of Stk would not change much.

9

You might want to give a look at raylib

10

Interesting but applications can have only one window ?? or am I wrong ?

11

I do not really know, I just know raylib is known as a good modern alternative to SDL, and it looks well designed with loads of features.

12

I have looked it up a bit, and it seems that yes, except that you can use multiple threads or multiple processes to go around it.

13

Thanks for looking at it. This may complicate things too much.

14

I do not find SDL to be very ideal, and in gamedev, it’s probably better to move away from it, and devise your own processing of events. The language like OCaml is very helpful in this regard, and eliminates the context in which SDL has existed — the C++ and C development, or other languages and systems that make high-level abstractions and modularity truly challenging.

With the use of EGL, the problems of compatibility are much easier to tackle. I think, the only remaining issue with any APIs related to graphics hardware on modern systems are more about the use of compute resources (like CUDA), than graphics proper.

Thus, an EGL backend, or some abstraction level on top of it would make a lot of sense.

I recall a discussion on Cohhttp’s github or mailing list about what difficulties they have experienced when they tried to use both Async and Lwt. However, it seems to me that limiting to one event library only is very, very limiting (no pun intended).

I think, there’s a lot of value in high-level GUI library for OCaml. Bonus is if it would be usable also in js_of_ocaml. In practice, when doing development for anything remotely graphical UI related — including browser-only apps — there seems to be a tendency to develop one’s own library to encompass translation from higher-level declarations into the desired layouts. Thus, I think there’s a need for a GUI library that could be functorized to use different event systems and different graphics output engines.

All in all, I think that the essential problem that should be tackled is what is the optimal and stable set of high-level declarative specifications one could work with, in order to translate them into working GUIs. The graphical heavy lifting should be done by hardware-backed backends, including as much of specific work like handling overlapping sprites, etc…

1 Like
15

A native ocaml GUI library abstracting underlying libraries used for events and rendering should indeed be great. But since stk is just a side-project on the road, I’ll stick to SDL by now, even if I may switch to something else if it becomes too limitating.