What’s the current status of the Python bindings for Haiku?
If I am not mistaken, in 2011 someone worked on a Python-related GSoC project for Haiku. Was something usable eventually released or are we still stuck with the obsolete (and probably broken) Bethon bindings?
And, above all, what about PyQt? From what I saw on a Russian website, it seems that they were working on porting a similar project, called PySide: http://qt-haiku.ru/index.php?option=com_rsgallery2&page=inline&id=59&Itemid=64
but apart from the screenshot, not much information is given on that webpage. Does anyone know something about it?
Has anyone managed to use Qt with Python in Haiku?
I’ll go along with that. I suspect, though, that one of the reasons it’s hard to get a handle on scripting is that too few of the handles are useful, if you will. Application authors haven’t as far as I know been adding a lot of direct scripting access to application functionality. Inheritance of scripting support gives you access to a big mess of graphic elements, but that isn’t usually what you want, and even if it is, since the graphic elements have to be reached through a structural traverse, it looks like there’s a lot of potential for breakage in the next application revision.
Maybe evidence of cultural change over time. In some ways, BeOS and Haiku follow in the same vein as the Commodore Amiga, where scripting features were heavily used. Be must have been impressed by that, to have grafted scripting into the API the way they did, but among the BeOS user and developer community apparently little interest in going beyond “hey” with it. And I think that applies more generally to alternative development environments - more interest in full, hard core application development, less in quick and dirty integration etc.
Personally, I haven’t heard any new news of python since the initial task was completed by a GSoC student. It’s unfortunate. As I understand it there is no TkInter port or bindings so we’re stuck with terminal programs. As far as the Qt/python port - haven’t used it myself.
For me, it’s a little disappointing to have several languages to use in a semi/mostly-complete or non-maintained state (think OpenJDK, Python, YAB, and now add GO as well). I can only imagine the HUGE amount of work that was put into each of these projects, but what is their status now?
I’m sure this next statement will be less than popular with most -but it’s also possibly counterproductive to keep adding more cross-platform support/languages to Haiku. Yes, these things help us add more applications from other operating systems and projects. This is the positive side. A negative aspect may be that your attracting developers whom are only semi-devoted (at best) to Haiku. Personally, I would like to see Haiku have unique software that you can’t get on the other systems. If I wanted cross platform tools and applications, I might as well use linux. BeOS set itself apart by doing what was better (and consequently sometimes different).
As a user and in my opinion Haiku should offer two languages. C++ for the experts using an IDE of choice – or- YAB and its IDE for the rest of us possible budding Haiku users/developers. By limiting choice here we avoid the fragmentation that plagues linux. By using these two options we also use Haiku UI instead of having developed programs that sort-of fit in (this includes QT/TkInter/Swing).
C/C++ is completely weaved into the system as it’s built on it - correct? Maybe add more features to Paladin?
YAB and its IDE needs more support. It should be the VB of Haiku, where anyone can make first crack at programming. Gradually as the YAB users grow more experienced, they might then venture into C++.
If I understand the state of development correctly, we have a small (but good) development team. The same can probably be said for the users as well. Consistently adding another project takes away resources for those projects currently on the table. Limiting choice and avoiding fragmentation may be more beneficial- at least during this phase of popularity.
Sorry - not trying to hijack your thread - just my opinion on the matter.
I am not sure that I agree with your argument against having too many languages. For sure, I know that many people will disagree. Anyway, restricting the number of languages to two, as you propose, certainly seems a bit too limiting.
Don’t you think that it would be better to also have (at least) another language, say Python (for semi-professional/professional use), between C++ (professional use) and Yab (beginner/amateur use)? I personally believe that such a language is a must. Whether it’s Python, Lua, etc. is another matter.
Yeah, maybe two is a little harsh. Python would be a great choice for a middle of the road language. It was the first language I used when I started in college. I still have all of my books.
It just seems like we have too many open language projects and not enough people to maintain everything. Finishing/maintaining any one of them would be beneficial. In any respect, It’d be nice to see these languages use Haiku’s native GUI widgets. If Haiku could pick a path I would be happy with it.
Too bad this year’s GSoC projects didn’t include binding Python or maintaining/improving the OpenJDK port.
Of course, I have no influence on these factors - just a user, just a suggestion. Thanks for the respectful response.
but, making python bindings to the haiku API would make it possible for python developers to write haiku-native code in their language of choice rather than generic portable modules as is the case currently with the python port, which exists and isn’t likely going away.
back on-topic, there was also libcharlemagne, but development on that seems to have stopped about three years ago.
I am still not clear about the 2011 GSoC project on Python for Haiku. Wasn’t that supposed to take care of the Python bindings for Haiku?!? If not, what did it accomplish?
– Python and Haiku: I’m going to go out on a limb and predict that no one will ever produce a full native API binding for Python that satisfies everyone. The languages are so different - and the need, really, isn’t that great. Maybe I’m wrong, but right now with the operating system still in alpha is not the time to be expecting anyone to put in such a tremendous effort.
– the supported alternative should be [yab, python, lua, perl, haskell, …]: ha ha ha!
Haiku has been in alpha for many years. If it can break out of the back bedroom and out the front door and hit the road with a user release that really functions like it needs to – e.g., web browser that can handle normal browsing – I think we’ll see more cool stuff coming along behind.
most platforms supported by python weren’t in near as usable a state as haiku is when that support began. but there is a haiku port, and even in its current state haiku’s api is pretty stable (if poorly documented) so there isn’t the problem of a moving target should someone choose to pick up any of the three efforts to write bindings.
but, better documentation of haiku scripting would be pretty nice right about now (“hey” is pretty dang adorable), and the scripting itself would require fewer hoops to be jumped through than python (i remember reading on the mailing list that replicants are near impossible to implement in python, for example).
Putting in scripting means starting with it in mind when writing an app. The technique I use is to have everything done by messages to the BApplication. Besides scripting calls via Hey, command line arguments and UI actions also work by sending BMessages to the app. Not sure if anyone ever used it, but the spamdbm (formerly AGMSBaysianSpam) had scripting support (including built in docs via the Hey GetSuites command) for everything it can do.
I was actually curious about this very same thing about a month ago. After asking around in #haiku, I was able to locate the old source code from the 2011 GSoC. I decided that this probably would be a really useful thing to have working so I started trying to package up the bindings to work with the current build system.
I have created a project page for these bindings here:
I haven’t gotten back to working with it for a while but, last time I checked I was able to get at least the demo program running.
I am very glad to learn about the PyKu project. That’s exactly what I was looking for.
Does this project have some (official or unofficial) special status within the Haiku community? In other words, should we assume that this will be the best developed and best maintained Python-for-Haiku project in the years to come? Or are there other parallel projects that might rival with it for such status?
In my original post I mentioned PySide and PyQt. I really wish someone could shed a light about the realistic chances of actually seeing either of them ready on Haiku in the near future.
About PyQt, it’s already available in HaikuDepot for x86_64. An app using it is Openshot (also in Depot).
I thunk PyQt is at the moment limited by the capabilities of the Qt port (no audio available it seems).