So as not to pollute the “Where to innovate” thread any further…
As some may know I’ve been looking at creating bindings for the Haiku API for other languages using SWIG. This is going OK so far, just a few growing pains I’m discussing with the SWIG developers.
What I’m interested in knowing is the following please:
What languages, if they were available, would you consider actively developing apps for in Haiku if the APIs supported your language? (E.g. python) - and I do mean “actively develop” and not “hey it’d be cool if you supported my fave language so I can run someone else’s apps” - I’m interested in encouraging new Haiku apps to be developed in this topic
Who would be willing to write tests in these target languages? - without tests the bindings will atrophy and die. To succeed, others will have to chip in to this effort
Who would be willing to help write docs, run tests, report bugs, and so on for this effort?
Finally, if Paladin (or other Haiku native apps) supported plugins written in other languages, would this be a useful feature set to target also?
I don’t want to put a lot of work in if this isn’t going to be used.
Equally, I don’t want this topic to descend in to a religious war on languages. I only want to know who is prepared to step up and help. Please only reply if this describes you!
I would certainly explore the bindings for Python. Depending on the complexity, I am not sure if I could be able to develop a full application for it, but I have already one or two interesting ideas that could get me busy.
I have been using Python with tkinter/ttk to build a few desktop apps on macOS for some time, but I have little knowledge and no experience on C++. For someone like me, having nice Python bindings would be a great plus. But right now Python seems to be in need of some additional development on Haiku. Managing dependencies and virtual environments is still very far from what we can find in any other platform. pip is half broken and there is no clear way to create a virtual environment that includes binary packages that are not shared with the system or with other Python applications in the same computer.
Have you looked at DarkWyrm’s Haiku programming tutorials? The BeAPI make C++ programming a snap. I used to work with the guy who did Bethon ( old attempt at binding python to BeAPI.) The project faded because everyone involved, including the community came to the conclusion that binding python to the BeAPI was more trouble than it was worth. It actually made both python and the BeAPI less fun. I’d rather see tkinter working.
I’m the culprit behind what I believe are still the closest thing to Python bindings. I’m not sure which was worse - that not many people used them to develop software, or that some did. Users are a pain in the butt, as we know. Someone has to deal with new Python versions, and inevitably one of the handful of users will need some feature that isn’t supported by the binding. I’m sort of joking, because that’s why we do this, but then there will come a day when it doesn’t really add up to being worth the trouble. Part of that for me is that I lost a lot of my enthusiasm for Python. Since it sounds like you don’t care about Python (whatever language it would be) to start with, that wouldn’t exactly be your problem.
I still like to mess around with this stuff once in a while. Along those lines I have Haskell bindings that are at least good enough for my own use, and recently it occurred to me I might revisit ocaml (I think the last time, years ago, the support wasn’t there for concurrency.) I’m a big fan of functional programming, strong static typing with type inference, various features of these languages.
But I would not encourage a Haiku developer to go down that path, it’s just for those who are more into the experiment than the product. The Haiku API is C++, and fortunately rather simple C++ at that. It isn’t my favorite language, but it’s fine. After C++, the next priority probably should be Java, and while I doubt API bindings would be used much directly (because Java has its own kits), the similarity between the two languages might make for fairly easy slogging.
Well, after a bit of playing around with SWIG, I’ve got the first Python / Haiku GUI App working. See the below image.
As you can see, it’s a highly sophisticated app!!!
Got a few memory glitches (crashes currently on BWindow destructor), and need to work on keeping the app running in Python (python tries to immediately shut down post init), but they’re relatively easy to solve.
I’ve now got a few samples in Python working. I started on the base classes and built my way up. Pretty much got most of the useful stuff in Support Kit included. Working on the Interface kit now.
Once I have a nice working basic app with labels and buttons, I’ll report back. Looks promising though, and not that much extra work really.
Yeah ruby is high on the list as it’s binding support in swig is really good. Already started shelling out a couple of basic ruby example in the repository.
I like the python swig bindings (following the repo silently) as that would allow quick iterations, but i miss the pythonic way of having the attributes named so you could call in different order (i think it’s not done automatically by swig, may be wrong).
Also dislike the need for the helper class, we need to get a solution for that, native one tho.
There are usually ways to automatically rename classes and method calls for a target language to make them feel the same. I’ve not done that yet.
I’ve got lunch with one of the SWIG maintainers on Thursday, so plan on asking about the octal enum issue. My gut feel is that a 5 line macro in SWIG should take care of it. I can’t believe we’re the only people doing that.
Can you please give me an example of what you mean around attribute naming? I want to make sure I understand correctly.
I’m going to continue to document things I find in the DeveloperDocs/issues.md file on the repo. There may well be a few simple tweaks to the Haiku source code that make this easier that won’t break anything that’s already there. Naming enums for example (I’m thinking of window flags here, in particular). Not sure if that will make a difference… I’ll know more after Thursday.
You can see them creating a serial interface by params and by named params (where you can swap the order). I dont know if swig generated source works that way with human named params like “host” / “port” or just use mangled ones like “par1” / “par2”, … Doesn’t matter for code, api creation nor anything, but looks more pythonic for me.
That’s probably because the API is in idiomatic C++ and you are trying to get it working in a c+±like python (which obviously is what we can do without more experience).
I have been experimenting with pybind11 (which is muuuuuuch manual wise than swig, but its definition is in cpp with easy syntax, helloworld gets rolling fast including enum-eration definitions) and reached the same api-status as your 002-first-app and ran it (actually, just used your example script). Seems like both libraries fail at the same point, when the App init tries to delete the window object because it’s a local variable for the constructor method. That doesnt look good even in the c++ code…
If you either attach the object to the app object, just calling:
self.window = MainWindow()
Or customize the binding in pybind11 to not autodelete, the interpreter doesnt trigger the deletion of the window object and you can play around with the window (i.e. the application doesnt close).
However, this doesnt work well, because after clicking the window manager close button, the window closes but the application keeps running. The methods to receive messages are not called, so it cannot send a message the looper / parent to process the quit signal, and finish the script.
Just tested on both your swig version and my pybind, doing the “self.window” change without success.
Haha yeah it’s a good API, but the idioms are not common enough for there to be SWIG macros already.
I’ve been tracing the destructor issue and have a variable saving a reference to the Window object, yet the destructor is still being called. I suspect some weirdness in how the wrapper C++ code is handling pointers. Hoping to get to the bottom of it on Thursday.
I believe there’ll probably need to be around 6 helper classes or macros created to handle the bulk of differences in how the Haiku API works. Thankfully it’s a pretty consistent API. Once I get to the bottom of it I’ll let you know.
Yes, after testing, that solves the problem of closing the app with the main window, but no what I said about not receiving messages.
I was just “translating” the main app from a paladin template, which did the quit on close automatically
without that flag set.
Also, something is not right on my side, cause with this “fix”, and having a reference to the window (preventing delete) caused another error on app cleanup regarding numblocks (whatever).
