Just what the title says. I’m a Python programmer. Maybe one day I’ll get around to actually tinkering around with it. There’s a lot to learn first 
1 Like
Using Python ctypes seems to be pretty straight-forward. I think the bulk of this project would just be wrapping the GUI functionality one class and function at a time. It wasn’t a difficult task to create a wrapper for creating a single ‘Hello World’ window.
Edit: I think we should go with Python 3. Haiku won’t be ready for production release until about the same time Python 3 is ready and accepted by the community. Python 3 is backwards-incompatible with Python 2 in many places.
There is a BeOS API interface library for Python, “Bethon”. Most of the GUI is accessible through that, though a few things are missing for various reasons. Some things won’t work in any interpreted language, like the `replicant’ feature; others are hard to model in Python - C++ function overloading, the data structures under the scripting system; and there’s new stuff that no one has tackled that may or may not work out - the layout system, for example.
It works, well enough to write an application for your own use anyway. It fills a pretty small niche, though. It’s hard to imagine that anyone could write much of an application without encountering the need to write part of it in C++ anyway. And honestly, if you try working with the C++ API directly, you may find that it is pretty painless (especially when you don’t have to write Python interface code for everything), and it gives you a simple executable that has no Python+library dependency, can have icon attributes, etc. Bethon isn’t a very good introduction to the BeOS API, since there’s basically no documentation other than some examples - the idea is that you know the BeOS API and extrapolate to the Python equivalent.
On the bright side, I never had any of the troubles with multithreading while working with it. Some people hold this against BeOS as a mortal flaw, that the GUI is multithreaded, and in fact back when I worked with UNIX/Linux I wouldn’t touch threads with a stick unless there was a very compelling reason for it. But the Python interpreter doesn’t support parallel execution - external functions can execute in parallel, but not Python code itself - and that may provide just enough slack in the concurrency that we avoid problems, at little cost in throughput (since resource intensive computations are rarely pure Python.) … Or it could be just that I rigorously limit thread interactions to message I/O in my applications. My opinion is that the multithreaded GUI is a great idea and perfectly reliable, if you carefully segregate data per thread and rigorously avoid concurrent access, but I don’t have a lot of pure C++ application experience to back that up.
Proving that I’m someone who learns a little from his mistakes, but never quite enough, I have an interface library under way for the Haskell programming language, if a production release of Haiku ever arrives. It’s a compiled language, and the `foreign function’ interface is much easier than Python’s - but it isn’t object oriented at all, so the API translation is a little awkward. Haskell is a more interesting language than Python in various ways.
But feel quite free to forge ahead with a parallel effort. Bethon started with Python 1.52 if I remember right, maybe earlier, so it’s based on a primitive view of the C interface, and the module generating software is a mess of ad hoc stuff that no one could possibly understand. I am happy to take some responsibility for it, but lost interest in Python years ago, so it isn’t in a great position to make giant strides forward. (such as, for example, the transition to Python 3.)
Awesome! I didn’t realize Bethon was still in existence. I have seen it before but I couldn’t nail down the location. I assumed it evaporated into vaporware.
Yeah, that’s sort of what I figured. But the other alternative is migrating something along the lines of tcl/tk and I think a native GUI kit would be better. Unless, of course, nobody uses Python in Haiku than it wouldn’t matter either way 
That is an excellent point. I did notice that when I ran my application, I had a Python Process/Thread and then underneath that was the actual BWindow. I’d have to find some way of getting around that issue. The C++ API is very friendly, especially compared to other GUI APIs out there. On the other hand, dynamic languages offer some great benefits that are beyond the scope of this forum.
Of course there will have to be quite a bit of garbage collection and what-not going on to make sure the C++ Objects aren’t destructive. I think it’s safe to work on a ‘proof of concept’ core first and later expand it.
Maybe I’ll create a “simple” API first that will just be a very dumbed down subset of the Haiku API for letting Python applications use the most basic (but common) functionality and later add in the rest.
I think a project like this would have to include outstanding documentation as a core goal. Most Python libraries I’ve used are very well documented and it wouldn’t be much fun, or worth the effort, to try and use one that isn’t.
Very nice! Feel free to share it when you get it to that point. I’d be interested in seeing what kind of relationships you setup between your Haskell Library and the Haiku C++ API.
There’s a Haskell API example in the GHC haskell compiler' thread in theNewbie Developer’ forum, just a brief illustration of how we deal with the C++ virtual functions that the GUI is built around.
Are you considering creating Python bindings to the Haiku API?
This was Sean Healy’s goal for the Google Summer of Code 2011. Please see the link here for more information:
I guess he completed it successfully, but I’m not sure if his work ever got merged into Haiku (or if that was even the plan).
[quote=drcouzelis]Are you considering creating Python bindings to the Haiku API?
This was Sean Healy’s goal for the Google Summer of Code 2011. Please see the link here for more information:
I guess he completed it successfully, but I’m not sure if his work ever got merged into Haiku (or if that was even the plan).[/quote]
Nice! I just took a look at that but – I can’t tell on the progress. From the look of the source code, it appears he got quite a bit accomplished considering he took on two languages at the same time. Thanks for the link!
IIRC, Sean is still on the mailing lists (at least haiku-development or haiku).
I think there is value in exposing the Haiku API in scripting languages, though some may be better than others. I’m interested in Ruby and JavaScript, the first through the Rubinius VM (which has nice thread handling and a decent native interface) and the second through V8 (the Chrome JavaScript engine also used for Node.js.)
As already pointed out the Haiku API isn’t bad for being C++, but unless you are a really good C++ programmer using something like Ruby or JavaScript or Python will just be faster (in development speed, not so much in runtime speed, but we all know the trade-offs.)
The good news is that all these projects have some common needs, like a GUI builder, of which there are already a few projects, such as Jon Yoder’s, which is part of his Paladin IDE:
http://paladin.cvs.sourceforge.net/viewvc/paladin/PDesigner/
Speaking of Jon, he also has libcharlemagne which he created for his GUI builder, which exposes the Haiku API in a very generic C interface. I got him to put it on GitHub because I was interested in hacking on it, but I haven’t had the time yet:
https://github.com/darkwyrm/libcharlemagne
This is something else we all may find useful for the various alternative language projects.
Also though I’m just a very, very beginning Haskell programmer, Donn’s project has always been interesting. I look forward to checking that out more when I can.
To conclude I think making Haiku development faster however we can is a great idea. Let’s just be sure to not re-invent the wheel, though maybe in Kurtis’ case it is a good learning experience.
Well, as it turns out – C++ isn’t a very “extensible” language. From what I read, this is due to inconsistencies between compilers which probably makes it a nightmare.
So, I took the route of creating functions as C extensions. Then, I was able to call these easily from Python. I was able to create a BApplication, BWindow, BLabel, BRect and throw it all together – essentially following darkwyrm’s Tutorial #14 and extending the inherent ideas a bit. Everything seemed great! It wouldn’t be tough to set these up as Python classes and make it feel like a Native python library.
Well, I moved on to Tutorial #15. That’s with the introduction of Message Passing. Unfortunately, since a lot of this code has to be embedded within the Classes themselves, I’m really not sure how to open them up to a C API (and consequently, to Python or any other scripting languages). Maybe it’s just late and I need to look at it again another time
So it definitely is feasible to simply create a bunch of GUI elements. It’s a breeze. Unless I can figure out how to open up a C API to catch the messages and act on them accordingly, it’s not going to be very useful.
I took a quick look there. I’m not sure the C Interface is exposed in the way I need – but I plan on looking again now that I’ve got a better idea on how I would like to structure it. Thanks for the good info!
If anyone has any ideas, I’d be happy to hear them!
Edit: Just wanted to share a screenshot.
The way I read it, you are looking at the virtual function problem. Your application code hooks into the GUI event dispatch with virtual functions. I think it’s likely that any way you come at it, you will need the following three elements:
… and whatever it takes to hook those up. There are plenty of subtleties that I’ve forgotten.
(… oops, extra post.)
[quote=donn]The way I read it, you are looking at the virtual function problem. Your application code hooks into the GUI event dispatch with virtual functions. I think it’s likely that any way you come at it, you will need the following three elements:
… and whatever it takes to hook those up. There are plenty of subtleties that I’ve forgotten.[/quote]
Hey Donn,
Thanks for the advice. That may be a great, if not the only, way to go about it.
I’m concerned with two pieces, though.
- That's a lot of layers of abstraction just to get to the native code. Do you see this severely affecting performance?
- That sounds like a ton of work considering how large the API is and how many changes are most likely going to crop up over a short period of time. Do you happen to know of any ways to tie directly into C++ code assuming that it's only going to be compiled with one Compiler? (e.g. GCC4).
On the bright side, if I (or someone) did the work of abstracting the API and creating C extensions, it may something that a lot of others would re-use and potentially help develop.
I don’t see this stuff as particularly compute intensive, so I’m not surprised to have noticed no performance problem. In any case, that some extra computational resources may be required seems more or less a given, if you would have a Python interface for the BeOS API, true? This part of it seems like it would be the least of your worries. I don’t doubt that a sufficiently motivated programmer could manage the C++ `mangling’ system, but it wouldn’t be worth it. Each of these layers will have work to do for you anyway.
It is of course a certain amount of work no matter how you go about it, but I think if you start writing C modules for each class, it will quickly become obvious that you’re repeating a lot of boilerplate code in a way that’s both tedious and prone to error.