There must be some mistake. Last time I checked Tcl/Tk worked fine and could run real-world apps. It was just confined to an SDL2 window. Did it break in the mean time?
That said, you could try Yoshi, or for that matter cut out the middleman and learn Yab.
Edit: turns out you have to use wish. Can’t load Tk as a regular package as per modern Tcl practice. Must be yet another artifact of using UndroidWish. But it works, if clumsily.
I’ve been fiddling around with Ocaml bindings for some time, just got a major rewrite running yesterday evening.
Ocaml is in principle an object oriented language, and the OOP features aren’t entirely useless here, but they aren’t essential. What really hurts at the moment is all the overloaded functions from the Be API - and I can’t think any other language that supports that feature.
Then most languages will have a runtime that manages memory etc., that has to be interlocked for multiple threads, so you have the potential for something that works pretty well 99% of the time but locks up on rare occasion.
I started out on this path in the '90s on BeOS thinking it would be real useful for trivial applications that weren’t worth diving into the complexities of C++ (which was less complex then than it is now), but I don’t know. I wonder if there’s a productive alternative using some kind of wrapper that boilerplates a few basic interface classes and gives you a place to drop in your application code.
If anyone’s interested in reviving it, there was a BeOS language called Squirrel (not the one that’s in the depot now) based on LOGO. It’s in HaikuArchives under the name Squirrel99.
Agreed we should take this off this forum, but we’re eight timezones apart so I don’t think IRC is going to work for us. The orgfree forum has been very quiet lately.
The problem is baked into the nature of C++ which is used to develop the entire operating system as there is no easy way to achieve that level of interoperability.
One possible solution is to generate bindings with more or less specialized tools like SWIG, CppSharp, bindgen, etc.
However, as @trungnt2910 said, bindings can’t be generated for many types.
See for example the LayoutBuilder I had to implement in C#:
There are a few language that promise some sort of smooth interop like D or recently Swift but not without caveats.
In any case, generated bindings only would not suffice as they would not use the key charecteristics of a language.
The Haiku paradigm transplanted into C# works, sort of. But it would be better to use preoper language patterns and statements like delegate and event handlers, for example.
During the glorious Amiga days I vaguely remember there was a tool running in the background (a Server we would say in Haiku) which let scripts for example create GUIs using an ARexx port and exchange messages to instruct the server to do the UI part.
Maybe we can create such a server in Haiku to decouple the C++ API by creating a message-oriented layer on top of it. It would be sufficiently language-agnostic and low level to let developers create their own classes in the language of choice using all the bells and whistles (and patterns) of that language.
At first glance, Fuchsia implements a similar concept where everything is a message including the instructions for creating a GUI.
I believe the mechanism for this in Haiku is the “scripting” feature addressed by the “hey” command. Some use has been made of it, but not much, because applications don’t generally expose useful application specific features. So you can get to the API components that inherit this scripting functionality, but you can’t get to the functions the user enjoys via the API.
Scripting should be used to control or extend existing applications. Here I mean a way to create applications from scratch with whatever language you prefer with no recourse to bindings.
The alert and filepanel commands are accessible to any language that can make a system call.Extend that priciple and you can make, maybe not major apps, but installers, wizards and so on. Which is what yoshi does, actually.