Hacker News new | past | comments | ask | show | jobs | submit login
Bringing Pyside back to Qt Project (groups.google.com)
94 points by kissgyorgy on April 19, 2016 | hide | past | favorite | 10 comments



This is great news. Qt is really missing a scripting language story. Having python bindings as a first class citizen might bring a competitor to Electron, node-webkit etc (Qt has a chromium port).

Python is good, but I would love to see javascript bindings instead. Such a thing would make worthwhile node competitor.


Qt5 has JavaScript all over the place.

JavaScript is the language used for the QML declarative GUI system, which is encouraged as the graphical basis for new Qt applications. That is based on QScriptEngine (based on V8) which is also usable separately from non-QML applications. QObjects that have been registered via QMetaType can be easily instantiated from inside JavaScript. On those QObjects, methods that have been declared as slots can be called painlessly from JavaScript. For a property to be accessible from JavaScript, it does have to be setup with Q_PROPERTY instead of just being a member variable, which is a bit more work on the C++ side, but once that is done it too is fairly seamless to the JavaScript engine.

Also, there is Chromium as QWebEngine, since you mention it. Its JavaScript is less seamless with Qt since the two sides have to communicate via websockets. Previously there was QWebView which was more nicely integrated in with the rest of Qt, but I guess WebKit and Chromium both progressed in ways that were incompatible with that, thus its replacement.

If you want to write a Qt application in JavaScript without writing a single bit of C++ you can do that with QML. If you want to write a traditional QWidget application in JavaScript then you will need to write a certain amount of bootstrap code. I would imagine there is room for improvement here, but it certainly isn't fair to suggest that there aren't JavaScript bindings or that they aren't officially supported as part of the project.

Since you mention a node competitor, it would be interesting to try to use the Qt network server parts of the library to write a server in JavaScript. Perhaps it would inform me of areas where Qt's bindings for JavaScript are weak.


> If you want to write a Qt application in JavaScript without writing a single bit of C++ you can do that with QML

Not really. You cannot write full blown business logic in javascript, you almost always end up in C++.Even simple things like accessing the file system or networking or process management are not available in QML. One has to write bindings for it from scratch. This is what I was referring to in my original comment. If we have proper bindings (like the PySide integration), then we will get all these APIs.


I think PySide was the most sane use of Qt I ever experienced, but I didn't do anything too extensive with Qt and Python. It was as simple as a pip install pyside for me to use though. I hope this ends up working out, I would of never guessed PySide was an official project at one point.



Doesn't look like a really large list. Why are there 2 different python bindings then?


Licensing and stewardship at the least. 7 years ago, back when Nokia's coffers were fat and they could afford to fund the original PySide, for some reason they could or would not just buy up Riverbank Computing. That's the (presumably commercially successful) business that develop PyQt and sell licenses and support contracts for it. Architecturally PySide has a few incremental technical advantages, the kind you only get with hindsight and cloning an existing project, but overall it looks and feels pretty much the same and was intended as a compatible work-alike of PyQt.

I've a feeling there is a lesser told story in here somewhere relating to Riverbank. No doubt they had been approached by Nokia back in the day, and possibly also more recently by the Qt Company.

edit: https://wiki.qt.io/PySide_FAQ:

> Initial research into Python bindings for Qt involved speaking with Riverbank Computing, the makers of PyQt. We had several discussions with them to see if it was possible to use PyQt to achieve our goals. Unfortunately, a common agreement could not be found , so in the end we decided to proceed with PySide.


No LGPL with PyQt is the most important one.


This is fantastic news. PySide with Qt 4 has been an incredible asset to our business, and is truly a pleasure to use.

We've only encountered two bugs over two years of use.

Multi-platform python3 UI apps that work out of the box - amazing!


Good to hear, I used it extensively for a few internal tools 5 years ago, and after the few major kinks of the first releases were fixed, it was a pleasure and incredibly productive.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: