there are already python bindings you should look at updating perhaps and yes they use swig from what I remember.
1 Like
That repository is old; there are newer API bindings at http://haiku.healynet.org/cgi-bin/fossil/haiku-api-bindings/home
1 Like
That is interesting. I didn’t know about those bindings. Is the project mature and stable?
I am a big fan of Python, but I would add that it would be great (if viable of course) to have the Haiku API available in other languages that are gaining some traction these days, like swift, rust, go.
Is there any port of Elixir for haiku yet (just curious)?
Having a diverse set of development tools, especially if it includes the ones people are looking into right now, is a good way to increase chances of getting new developers interested in the platform.
I would like to see some changes to Haiku apps/app_server.
- Possibility to hide window frame or/and window tab.
- Change behaviour of Scrollview/bars so its not need to ocupy space all the time (see OS X).
- Dropshadows/Blur etc
- Animations
1 Like
As the millions line of code in Haiku shows… 
If you have memory leaks, the problem is not using the wrong language. The problem is using the wrong developers. Put the same developer to work with Java, and your application will need gigabytes of RAM for no reason. Put them on a Javascript task, and they will have something that doesn’t work on all browsers, outputs a lot of errors to the console, and is needlessly slow.
We have been running in circles for a few decades. Just talking about memory management, it goes something like this:
- First, a very simple but manual way to manage memory (malloc/free)
- Then, something more high-level and a little mode automated (C++ RAII)
- Then, someone tries to remove the initial simple thing because “it’s not needed” (Java, Garbage collector)
- But then, there are performance problems, or you need to trigger the gc manually because in some place you do a lot of allocations, etc
- Eventually, you get something like Rust: supposedly high-level, but people end up using “unsafe” anyways if they want to.
C++ is great because it lets you decide on a case by case basis what is the best strategy. Sometimes it’s reference counting pointers, sometimes it’s a fixed pool of objects, sometimes it’s allocating on the stack. All of these have valid use cases, and sticking to one single pattern is nonsense. This indeed makes C++ a little complex to master, but then you only have to learn one single language.
Now back on the topic of layouts and everything. I wrote that I don’t see a problem with the current solutions. This is my input as someone who write applications. I have little use for “some poeple may have problems with it”. Did you encounter problems layouting your GUI? Do you know someone who had problem with it? What exactly was the problem?
I can’t see how switching from C++ to Javascript would help. I can very well see how addind a purely declarative language would allow people to experiment a little more easily, maybe (but you can’t make me believe compiling an app is a complex task. it can easily be automated, so do that for your UI designer).
I don’t think a new language will bring any new features. It will just be a different way to access features we already have. Which raise the question: are features missing? Or just unreachable because of a programming language barrier?
Language bindings are yet another thing. I can understand that a Python dev does not want to learn C++. That’s fine. Someone has to write the bindings and we’ll add them to the repos, no problem. But the Haiku team will continue to use and advertise C++.
In the current state, I would say the most missing thing is proper documentation for all the layout support we have. The only article documenting it (“Laying it all out, part 1”) uses deprecated classes, making the C++ code a lot more complex than it should.
4 Likes
I think you miss the whole point. I am not sure if you don’t know it, or just behave like that. But I can’t believe you are not able to look beyond the end of your nose.
Having easy language bindings should be a primary concern of the project. The fact that you may not like a contextual language for GUI, for me just show you are out of that kind of industry. Having a C++ API doesn’t make sense if you don’t make way for adding higher level languages on top of it. I don’t see a problem if you want to program in assembly or in C++, but creating apps on Haiku is damn difficult for a number of reasons.
Language bindings, independently from the purpose, should be supported directly by the project and as said multiple times we should provide an interface for making that easily achievable. The fact that you continue to reply C++ is good for you doesn’t mean nothing, really, in the world out there.
3 Likes
Disagreed with the tone, agreed on high level languages opinion here 
For me, a python frontend for testing a new app over a whatever-lang api is always a test, change, test, done without the compilation steps that may arise. You can always do the compiled version if you need more performance or specific gain.
But most expensive things right now, like neural network training, already began to place a C-core with py-interfaces to direct the workload.
2 Likes
High level languages and compilation are unrelated. Look at bash: low level, interpreted. Look at haskell: high level, compiled.
There are so many different things mixed up here…
- For me, compilation is a non-issue. Basically, I type “make && ./program” instead of “python program” in my Terminal. If your experience is otherwise, you have a build system problem.
- An high-level language is nice, but C++ is one. Have you looked at how BLayoutBuilder is used to build GUIs? I already asked, what do you find annoying about it? I did not get any answer about this. I’m ready to think about improvements, if I see a problem to solve. But so far I only get “some people may have problems with C++” or “creating an app on Haiku is damn difficult for a number of reasons”. How can I think about solving that, please?
I already used Python with tk in other contexts, and I did not find that amazingly faster to build GUIs. I already used Qt, and I found it not a pleasing experience mainly because of buildsystem problems (having to re-run qmake manually for no reason, messing with moc and the like), and also limitations in the framework itself (not having an actual MVC pattern and somewhat getting in the way when you try to build one, very limited test framework, and overall some parts clearly show a lack of thinking in practical use cases). I also used IUP, which is designed for use with Lua, but also works in C, and found it surprisingly nice for something that uses non-object languages. I also did a lot of worh with SWT and Java, which I find ok even if I still don’t like Java. And I’ve also worked with custom-made GUI originally developped for MS-DOS, which demotivates me and makes me want to rewrite the whole thing.
So yes, I think I have some understanding of GUI design and programming, thanks. I can certainly learn more, if you take the time to show me the problems you see, it will be an interesting discussion. But somehow I don’t manage to extract any information from here. What seems obvious to you is not to me, so please write it down.
1 Like
I’m not talking about the build system. I just mean you are doing compilation and then run (you already confirmed with the “make” sentence) and that’s one step that may or may not take extra time when coding what you have in mind. Prototyping. Also i dont code python nor c++ without an IDE (codelite / pycharm for example), so build system is out of the question.
I have developed and deployed 24/7 (console) apps in both c/cpp and python (depending on their task) and I had much (much x2) shorter development time in Py. Enough to get upper management to let me code more in it.
When i required a special behaviour (like some serial protocol), i just used a c/c++ shared object and used it on several languages (like C# or Python).
Do we agree on having a great C++ API? Yes.
Should the os use the C++ upfront flag? I don’t know, i wouldn’t do it. Experienced devs in other languages could take their knowledge to the coding part here and just interact with the API and the provided bindings.
1 Like
Yes, I have nothing against other languages. Python is great for fast development, but it is not because they removed the need to compile things. I still prefer C++, but that’s because I’ve spent years with it and it’s now my native programming language, basically. Whenever you read code I write in other languages, you can tell I’m a C++ coder trying to fit my ideas into something else. If you use Python a lot, I can perfectly understand you feel the same in the opposite direction.
Anyways, we have quite a lot of work to do on our C++ API already. I don’t buy the “it should be the project focus to support more languages”. The reason is, designing an API for a single language is hard enough, and if we do something generic that works both in C++, Python, Go, Rust, Swift, … we will end up writing a C API because that is still the only common subset, unfortunately. And this is not what we want. And we just don’t have the resources to build more APIs. This reasoning is void anyway, because Barrett, you are still thinking of the Haiku project as a design-by-committee thing and waiting for “the project” to move in a direction or another. This is not how things work here. If someone starts to work on Python binding, and it works and people start using it, then it becomes part of the Haiku ecosystem. Contributors will join, and more apps will be written using it. If that needs changes to code in the Haiku repo, they can submit change requests on our Gerrit or ask for our help.
If someone wants to design a Python API for Haiku, that’s great. Clearly, I don’t have enough Python knowledge to design a Pythonic API. Whatever I would attempt would be C++ thinking, somehow smashed into Python syntax. And that’s not what you want. I’m all for a great Python API for Haiku, but I can’t provide it. If someone works on one, and it turns out we need to make some changes in the C++ side of things, we can consider it if it doesn’t make it a regression for the C++ API when used by C++ coders.
2 Likes
Good explanation. I python-focused it (not intended) but i really meant any other lang that could benefict from it. Like lua.
“Wont” work because the same reason you stated above. Having a Python api itself wouldnt help, in case other languages (big ones) come into the table and having to redo the work in them.
Unless someone does the C wrapper for the C++ API. That could be (im)ported anywhere. A pity 
I thought there already was a partial C wrapper…
There are I think 3 independant attempts at Python bindings (2 were mentioned earlier and I think no one brought up Bethon yet), and probably at least 2 more generic attempts (one using libcharlemagne which is hand made C bindings for the Haiku API, the other using SWIG which I think was a GSoC project).
If all you want is bring up some windows, then IUP may be a possible choice (it has a C API, Lua bindings, and uses native widgets), but the port I started is not in an usable state yet. It would be great to see this running, even if it would not at all be BeAPI.
Bethon went with something close to the BeAPI, but as a result it does not feel like a 1st class citizen in Python, it really shows that’s its C++ under it. I think if we’re going to support other languages, we should aim for better than that?
Having used SWIG to gen language bindings for a C++ API I think it may be good to try this out again, perhaps with a couple of users for each target language just as a bit of a spike, to see how it ‘feels’ to use, and to see how much hassle it’ll be to create the bindings. There are 23 target languages possible with Swig.
I don’t think it’ll be too difficult to generate SWIG bindings for the Haiku APIs as they are very much pointer based, and have a pretty consistent ‘look and feel’ wise in the API from what I see.
The newish Python and Perl bindings link that was shared looks to have been updated just a few months ago, although I don’t know who the developer is. Does anyone know? They look to have been created using a custom Perl templating mechanism, and include quite a lot of custom / addon functions for each target language. I’d be interested in talking to the developer to see how much custom code vs. auto gen code it took to do.
They also included a simple Font Viewer app in Python as a sample for the target bindings. It may be good to generate the bare minimum bindings in SWIG for such an app for Python, C, Ruby, A-N-Other language as people see fit just to see what it looks like.
“Success” to me would look like:-
- Not a huge amount of work to add bindings for each language
- Doesn’t require N x changes amount of work for each small change/addition in the Haiku API (i.e. one function call change in Haiku should not mean manual coding in each of the target languages - that would be unsustainable from a developer time point of view)jump start
- “Feels” native in the target language (local idioms, containers, classes etc. translated to/from as appropriate)
- Would allow a dev in a target language to quickly stand up a custom app that they wouldn’t feel capable of doing in C++ themselves.
- Would expose and allow Haiku functionality to be used well in other languages (I’m particularly thinking of BMessage / BLooper etc here, but there are other things such as decorators, layouts, etc. that should be directly usable in a target language)
- Would definitely not require re–working of Haiku API just to get the language binding working.
Although SWIG looks dormant from the website as the last release was the start of 2017, it’s actually undergoing a major re-work for version 4. Looking at their GitHub site shows an awful lot of work on development. Perhaps targeting V4 now would be a good way to get ahead of the curve, should a spike show it to be useful.
I don’t mind having a stab at the SWIG bindings for a spike if people generally think it will be useful. I will want a couple of ‘native’ developers in each of the target languages to volunteer to write the samples and test out the feel of the API though.
Does anyone think this Spike on SWIG would be a useful short term exercise to do?
3 Likes
It is not a problem for me too. I am a C++ programmer and it is definitely the language I like among others.
What you don’t get here is that I never mentioned about removing BLayoutBuilder. What I am pointing out is the need to get an interface mechanism in our api to improve and partially automate the binding with other languages.
Is someone working on bindings? Are you? Are there some issues? What can we do to solve them?
BLayoutBuilder is already a “more C++ish” interface to the underlying things (BView and BLayout). It uses templates to provide a declarative-like syntax. Surely people can write low level bindings for BView and BLayout, and then use whatever makes sense in their language to expose that the the application developer. If, along the way, they find a problem, I can see if there is a way to help. Otherwise, there is nothing I can do, right? Or I could write the bindings myself, but then I wouldn’t use them so “other people need it” without actual examples does not motivate me.
I think the issue is that to create working bindings to our C++ API one needs basically to wrap everything. And AFAIK there’s no language out there that implements everything we have in our kits. To some degree this is unavoidable, there will be always parts in need of some special care, but, for a large majority of our APIs, we can:
- Have the messaging system more abstracted in a way that makes it more interoperable, especially I am thinking about the need to define messaging protocols in a way that makes them maintainable.
- Most of our interfaces can be abstracted one level up, using an IDL
- Most relationships can be modeled on top of an IDL and then they can provide a Binder (or whatever we call it) object. So that, just as an example, you can manipulate remote and local objects. As another example, a media node would be ideally implemented onn top of a Binder object.
- Once we have everything in place people can begin to work on top of that to provide bindings for any language, without having to rewrite the world, and automatically generating the basic interfaces.
The issue is that we should go for some special support to allow people port new languages on top of Haiku. Right now it is just a hazard. Since not everything can be translated from C++ to an higher level language, our API just doesn’t contemplate the concept at all. That’s the problem. This approach works very well on Android, I am not saying we should take the very same approach, but I am pretty sure the right solution would be something equivalent.
AIDL is a Java subset, (in particular something like Java interfaces), OpenBinder was a C++ like thing. FIDL (Fuchsia), seems more similar to the OpenBinder approach. And it seems obvious, since the primary purpose of AIDL were Java bindings, where FIDL is designed to be OS-centric.
Now, do we think SWIG is a more viable approach? Let’s discuss it. But don’t continue to tell me all this stuff like “I love C++ so blah blah…”. I agree with that mostly, but you seems to continue to ignore the fact that our API is very primitive on that level.
My short answer would be I think swig would get us 80% of the way there very quickly, but of course some bits of the api may need special handling. Not much I would have thought though…
I’m hoping to have time tonight for a quick spike on this, so will report back afterwards.
I’ll start with python for comparisons sake.
As an example I can give the BControllable interface. Ideally we need to make that available also to non C++ apps, but this is only a side of the problem. However, we does not supply any notion of remote and local objects. We don’t provide a sane mechanism so that controllables can broadcast parameters (I have at least a few bugs I could pose as evidence). We don’t have a way to deal with those objects, especially if remote :
- What is the remote object life cycle?
- How we can reference count an object?
- How we can acquire and release the remote object resources?
- How we can communicate with such object, is the object reference local or remote?
- (following) Is the object completely controllable through local threads? And how can I know if such an object has context-switch due to being remote, so that I can handle it correctly?
- How can I load an object server side, for performance reasons?
- How can I know if an object is locking on my requests or behaving async?
[…]
The answers, in the Haiku API, are: casuality. You don’t have a common interface to manage objects like that (and we have a lot of concepts in the OS that can be aggregated ). Each class has it’s own way to do things, and I have to learn always the specific API even if that functionality is deprecated.
OK so it appears that Swig quite likes the Haiku header files. Not balking at any classes or methods as far as I can see.
Can’t compile the output yet as both the python_source and python3_source hpkg files fail to download on the R1beta1 image for some reason… Not sure why yet. Anyone got any ideas? I’ll jump on IRC and ask in a moment…
For those interested in watching the work, I’ve put it in the open here: https://github.com/adamfowleruk/haiku-swig-api