Live data from Hacker News

Hello Qt for Python

blog.qt.io

131–140 of 176 posts

Re: Hello Qt for Python

#131
post #52

Earlier quoted context omitted.

Agree with having a pythonic API. There are already examples in the "Hello Qt" which are easily solvable: app = QApplication([]) # should read instead: app = QApplication() where the empty list is the default argument. Also app.exec_() # should be instead app.exec() as it is also in the C++ API. These small things make the difference.

exec is a reserved keyword in Python. The _ is there because the code wouldn't "compile" otherwise.

[deleted]

Re: Hello Qt for Python

#132

This is like 10 years too late. This could have prevented electron.

Most interfaces created through web technology would be incredibly hard and slow to do using pyside/pyqt. We take for granted the non-blocking aspect of javasript where in python in order to make a slick interface would require to deal with threads/GIL in a much slower interpreted language compared with javascript running on V8.

Qt (Qt Desktop) bindings for python are welcome. But, it's not a suitable for a viable replacement for electron. Maybe Qt Quick, but even qt quick has some decisions that can make incredibly uncomfortable to use in large applications.

Re: Hello Qt for Python

#133
post #7

Earlier quoted context omitted.

Permissive license.

So PyQt5 is GPL. Practically speaking what is the point of a new permissively licensed library?

PySide came to exist because Nokia failed to reach a commercial licensing agreement with Riverbank (the makers of PyQt). I guess one side or the other was asking for too much

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.

Re: Hello Qt for Python

#135

Earlier quoted context omitted.

Sorry, I thought it was generally accepted that Python's relationship with the GUI was troubled? Put in plain English it is like this. I write quite a lot of code that integrates various enterprise systems together. Things like EDI management, and 'brokers' between incompatible API's. It is usually a mixture of Python/Bash/SQL. It is not my full-time job to code, but I get things done. As complexity increased I learn…

And doing your GUI with Tkinter, which has an API that fits incredibly well with Python is a problem because...?

One problem I have with Tkinter is scrolling.

In other frameworks I just say "this frame (containing lots of widgets) is scrollable" by setting one property to true and it just works. Including vertical and horizontal scrolling, mouse-wheel support, and standard keyboard shortcuts like page-down etc.

In Tkinter this seems almost impossible. It takes dozens of lines of code; many events must be implemented manually, including low-level things like calculation of scroll offsets; good mouse-wheel support is very difficult; etc. It feels more like I'm _implementing_ (rather than _using_) the scrolling widget. And in the end it the UI flickers like crazy during scrolling.

Is there something I overlooked?

Re: Hello Qt for Python

#136
I'm sure others here have far, far more experience with QT that I do, I wanted to give my 2 cents: QT has been great for the experimental control software we run to perform experiments in our lab (https://github.com/LISE-B26/PyLabControl --- note, the readme is unfortunately out of date, but it should be ready in a week or two). I tried a good number of other GUI libraries for python, but pyQT just worked far more quickly.

Re: Hello Qt for Python

#137
post #122
post #66

Earlier quoted context omitted.

What would you recommend to someone who wants to write Python desktop applications today? I've used wxWindows way back when, and I'd hate to use Electron. Would you go with Qt for Python, or PyQT? Also, what's PySide/PySide2?

wxPython is a thing that exists, and I believe it has a similar mental model to wxWidgets. To be honest most of the QT solutions for Python are pretty fidgety . The recent wxPython releases (4.x) work out of the box direct from PyPI, not too much to worry about licensing. For Qt, it's... the licensing is usually just fine for people but it's complex enough to where things like maintaining your own fork (pretty easy i…

Isn't the licensing LGPL3? How is this confusing?

Re: Hello Qt for Python

#138
post #62

Earlier quoted context omitted.

How well does that work on OSX? I’ve tried many times over many years, but never got a satisfactory working Python + Qt development environment working on the Mac.

conda install pyqt

Why was this downvoted?

It will setup exactly what was asked for. Specifically qt 5.9.5 with PyQt.

Re: Hello Qt for Python

#139
post #122
post #66

Earlier quoted context omitted.

What would you recommend to someone who wants to write Python desktop applications today? I've used wxWindows way back when, and I'd hate to use Electron. Would you go with Qt for Python, or PyQT? Also, what's PySide/PySide2?

wxPython is a thing that exists, and I believe it has a similar mental model to wxWidgets. To be honest most of the QT solutions for Python are pretty fidgety . The recent wxPython releases (4.x) work out of the box direct from PyPI, not too much to worry about licensing. For Qt, it's... the licensing is usually just fine for people but it's complex enough to where things like maintaining your own fork (pretty easy i…

Qt license is pretty ok, it is just complicated for the typical crowd that wants to sell stuff built with free (beer) tools.

Re: Hello Qt for Python

#140

This is like 10 years too late. This could have prevented electron.

Electron is the third wave, before we had MSHTML and XUL.

Just like its predecessors I give it one or two years more max, then it will fade away like they did.

Post reply on HN