…just “discovered” that OBS Studio don’t have an Haiku port !
So far missing Qt5X11Extras …
Then we need first x11?
Reading up on it in between So far this has some useful information? https://doc.qt.io/qt-5/linux-requirements.html
I would not invest work into Qt5X11Extras, as it depends way too much on X11, for which a port exists, but it cannot draw on the screen at all, it is useful only for running X11 programs locally while displaying it on X11 capable remote host.
The related parts of OBS should be rewritten for Haiku, or the parts depending on Qt5X11Extras could be disabled, but god knows how much functionality will get lost.
If you have GTK 2 or 3 ported, then you can get the GUI parts of Racket working which means you get DrRacket, the IDE, fully functional. Racket is THE BEST scheme/lisp environment in the world. Their documentation is excellent. Their community support is excellent (on a Slack channel) and whatever you code just works on Windows, Linux and Mac.
The main reason the Haiku native API is disappointing is because there is no C native library so you can use a C foreign function interface o use so many useful development packages out there. For example, it would be trivial to use luajit to create native Haiku apps if you had a C native Haiku API library. [No, swig is not the solution]
And above in the messages, there’s a big difference between a hard bug stopping Mono from being ported as opposed to Mono working and then having to port in the GUI parts. Forward progress for anyone who wants to contribute is what counts.
Just a horrible decision by the original BeOS developers to have a C++ only API native interface.
There is no useful GTK ports and AFAIK nobody really works on it.
I try to get the Racket (without GUI) work on Haiku since years, but even with help from the Racket guys i was unable to get it work. So if you know Racket, you could help to get it work.
I was told there is/was C API, but it is unmaintained (?) bitrotted (?).
There are several C API projects on HaikuArchives which are completely abandoned and have indeed bitrotted due to the API changes (libcharlemagne, Habid).
It is entirely possible to create a C API for the Haiku API, in the strictest sense (perhaps an extern_c generator + wrapper on the development headers) but as always with 3rd party bindings, there is a degree of risk of it bit-rotting.
Making it a first-party one included in the Haiku source might address this problem if it is extremely useful and it should have little to no dependencies included. Again this is up to the core devs to decide.
“…this is up to the core devs to decide”
EXACTLY. Need to be a fully supported decision. C APIs are far more maleable.
Here’s the older versions of Racket, when it was callled PLT Scheme.
A '99 paper referenced PLT running on BeOS. If you download the last release there, 4.25, there’s a reference to BeOS in the configure script. This source won’t compile as-is. I got it to the point of compiling all of mzscheme but had linking errors. Only took 30 mins to get to that point. I got past the configure mainly by changing a few “#define”'s and pulling down the X libs from HaikuPorts (SEE, I told you guys that keeping X libs around is still useful, even better if there were an X server too. Didn’t BeOS have one?)
PLT Scheme v4.25 was still very advanced for its time. You can bring it up on Windows 2000 and it’s like wow, documentation is still great, detailed and it’s a full-fledged useful development environment…almost 10 yrs old now. If that got working, next step is to gradually compile the earliest versions of Racket (version 5 series) and work up to the latest release.
Tackling the problem from the current version, 7.x, is probably not the ideal way to go. Better to learn what they did with the code as the versions progressed from PLT. This is a very advanced, complex code base.
Link to old PLT Scheme source code versions:
Now the program thinks it can draw, while it cannot. X libs doesnt provides any useful functionality for Haiku at this moment, so in this case you just made it depend on a whole bunch of useless libs.
But i think it is clear for you.
BeOS had community provided X server port, Haiku Inc. (AFAIK) have no interest to coordinate any X11 porting efforts. The community can work on whatever they want of course.
In ideal world this would be maybe the right way, but ours is not that ideal. I try to build every new version, invested plenty time in the different configure options, but i was not successful yet. Maybe i should try with older versions too, but i am not Racket user, i just wanted/want to port it for the fame and for the cookies.
Don’t worry about the BeOS/Haiku C++ API. If you get to the point with your Scheme or whatever it is, that lack of access to the native platform is your big problem, you can whomp something up. The real problem there is not “an API”, but “a good API”, that meets various criteria for such things.
One of them is “familiar to anyone”, which may mean an adaptation to a language-specific package (like Swing), but that’s a little different than full access to the platform - that means importing native API functions to the language in a way that people can sort of puzzle out from documentation of, and experience with, the C++ API. Which will be no mean feat with Scheme.
You don’t need a C API for that, but what would help immensely is full declarations for API functions. “Machine readable” in a way that the standard headers aren’t particularly, but more important, they have to document storage semantics in a way that isn’t particularly needed by a C++ compiler but is of great importance to modern languages.
What does “status_t stuck(struct Muck *)” mean?
- Muck value is passed by reference because no one passes large structs by value. Essentially “const” but that’s omitted because that got hairy in the way it does. Modern language: stuck(Muck) [with compiler guarantee that stuck will not modify.]
- Muck value is passed by reference because there will be changes to it, that are of interest to the caller. Modern languages will differ on this one.
- There is no Muck value, it’s just a pointer to return a Muck value to the caller. Most modern languages, Muck = stuck() [including some facility for multiple return items.]
So full declaration just has to add a little info about whether there’s a value and what’s going to happen to it. I didn’t mention whether the function is going to squirrel away a reference to the object, but that’s necessary too, or the object memory will be inconveniently be reclaimed by the caller. There isn’t a lot of that in the API, but there is some. With all the bases covered, full declarations, ideally you can generate your API straight from that.
I got most of IUP running by using just C++. Other people got Qt and FLTK running as well. And it’s now possible to use Rust as well, and Python has been an ioption for decades with Bethon. So, apparently the C++ API is not a problem at all?
The decision from BeOS is very sane to me. C is just inappropriate for object oriented programming, and a GUI without that is just a pain to write. GTK tried C, and guess what? They eventually ended up using Vala instead, a language hiding their hand-made and verbose object layer under a more manageable abstraction.
The BeOS and Haiku API is designed for C++ and object oriented programming. It allows contained objects, making it a lot easier to manage things. It is not an API problem if all other languages can only bind with very primitive languages like C. It is as you were demanding that we provide our API in x86 assembly, because that’s the only real common thing between all things that run on your CPU.
As an Haiku developer, and application developer for Haiku, I am glad that the API is C++ and quite good at that. I can set up a working application in a few minutes, be quite sure that I won’t make too much memory leaks, that the window will run an asynchronous thread, etc. Yes, I’ve also done porting of applications and GUI toolkits and I had some problems, not particularly with C++, more with the fact that we use threads everywhere and some bindings and languages aren’t prepared for that.
Anyway, do you really think having a C API would suddenly, magically fix all the problems? We would end up with another way to implement objects, something maybe like GObject in GTK. Then this would still not match with whatever you are trying to bind it with, and you would get memory management and object ownership nightmares. Here is an example of how such bindings goes: Investigating porting OBS Studio to Haiku
The truth here is that binding any API in any language is just a lot of work and requires a lot of design choices and complex problems with threading, locking, object ownership, compromises between staying close to the original API and being more in the spirit the language you are binding it to. This is just a lot of work, and I don’t think the API being C++ adds or removes any part of the problem here.
When the all term is applied to a lot of languages, might mean they all have seen it as a good way to interop with current tools in most cases (FFI).
Despite Haiku being really ok done in C++, a C facade API over the normal API would be enough to do interopt from other languages. Yeah it wouldnt work the same way, it may need to be updated to mach the backend API, yada yada, but it’s like direct interaction where FFI is available.
Not stating your case, but the tools should fix this for you (like… having a Valgrind like software, precompilation checks, or memory manage api/libs ). C++ shotgun is powerful, but being able to shoot yourself… tsk tsk. And I say this coding in c++ for a living too.
A C API has to do with the ease at which it is to work the respective software package’s foreign function interface which is predominantly a C calling convention. These packages typically build their own abstractions for the GUI, etc.
I don’t know about the rest of you, but I find C++ not so desirable a programming language anymore. It’s was “90’s fun” when OOP was new and not so bloated, not 21st century “fun”. Ironically, I most enjoy programming in Scheme (Racket) / Lisp (sbcl) / Clojure…very old language roots. Even FPC / Lazarus (awesome Haiku port, BTW…thanks!) is more enjoyable to work with than C++ with the Qt5 environment. All just my opinion. If you personally think C++ is the most enjoyment you’ll ever have in your personal programming projects, by all means, keep at it. If I had to program in a C derived language these days, I guess I’d chose Go, nice syntax with CSP built-in.
If you have IUP ported, then the person who is working on the sbcl port could use this lisp package:
Not to be rude, though I feel this post has gotten a bit off-topic… Speaking of an OBS-Studio port, I’ve done some very preliminary work on porting OBS-Studio to Haiku, and I mean very preliminary, as I’ve not tested whether any of my code builds and most added code does not involve the video or audio layer just yet. Not to mention, there’s no guarantee I’ll be able to finish it with my schedule (this happened with me trying to port VLC 4.0 too ), so if anyone wants to check out what work I’ve actually completed, here it is : https://github.com/CodeforEvolution/obs-studio/tree/haiku
There are other OS written in other languages. For me, Haiku is fun (even if C++ is sometimes a bit quirky), and I’m quite happy with it this way. If it was otherwise I would be focusing my enery elsewhere, of course.
Of course, Assembly IS the way to go (I’m a hardliner) -> https://kolibrios.org/
Well, even if C/C++ are bit dated languages, are still preferred for OS developing and app porting.