Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hello Qt for Python

blog.qt.io

Post reply on HN
Print view View original

121–130 of 176 posts

Re: Hello Qt for Python

#121

Post by ssebastianj »

bitL wrote: post #61
opencl wrote: post #42

Earlier quoted context omitted.

Delphi is still around, as is the open source clone Lazarus. It's certainly not as popular as it used to be but still actively developed with people using it.

Yes, though Pascal is now a fringe language. I was mostly ranting about best IDEs Python has such as PyCharm, where one has to go back and forth between Qt Designer, some command-line compilation stuff and PyCharm. It feels like some ancient way to waste time doing trivial stuff instead of getting app done quickly.

Ha! I feel your pain. That's what I ended up doing for an application a few years ago, wrote a Python script to compile the Qt Designer generated code to Python code [0]

[0] https://github.com/ssebastianj/ia2013-tpi-rl/blob/master/gui...

Going back and forth between Qt Designer and PyDev was (is?) ancient. Unfortunately I couldn't find a way to automate the compilation step (perhaps with a hook from Qt Designer?)

Re: Hello Qt for Python

#122

Post by rtpg »

stavros wrote: post #66
mherrmann wrote: post #16

Very happy to hear this as the author of a PyQt-based file manager [1] and an open source library for solving the many headaches that come with developing desktop apps [2]. Once Qt for Python is stable enough, I'll be happy to switch to it from PyQt. [1]: https://fman.io [2]: https://github.com/mherrmann/fbs

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 in Python compared to C++) is not super easy. But there's decent Python support, so it's more "do you want to use Qt or wx". Both systems have good enough support.

Re: Hello Qt for Python

#124

Post by cpburns2009 »

stavros wrote: post #66
mherrmann wrote: post #16

Very happy to hear this as the author of a PyQt-based file manager [1] and an open source library for solving the many headaches that come with developing desktop apps [2]. Once Qt for Python is stable enough, I'll be happy to switch to it from PyQt. [1]: https://fman.io [2]: https://github.com/mherrmann/fbs

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?

One thing to keep in mind is licensing. PyQt is GPL and commercial licensed. PySide is LGPL.

Re: Hello Qt for Python

#126

Post by siddhant »

pen2l wrote: post #114
stavros wrote: 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?

Tkinter, it comes packed with python and is actually really good and really fast. In fact, when I tried variations of Qt for py, I just quit out of frustration with how things either didn’t work or didn’t work very fast, now I just stick with Tkinter.

Do you know of good tutorials on ttk? I keep on reading that the look and feel provided by ttk is much more native than tk, but I can hardly find a good relevant tutorial.

Re: Hello Qt for Python

#127

Post by nadioca »

Drdrdrq wrote: post #50
roblabla wrote: post #22

I've always found Qt and Python (PyQt and PySide) to be a weird match. So many times did I end up with cryptic segfaults in the python VM due to some python object being collected "too early", creating a dangling pointer in the C++ world. This can happen if you forget to set the parent object, for instance. I know that those are things you have to worry about when you write C++, but when in the python world, you kind…

This just means that wrapper around C(++) code doesn't handle resources correctly. As you said, once inside Python you shouldn't care about object collection process. Nothing should lead to segfaults, in worst case you should get an exception about missing parent ref.

more exactly “underlying C/C++ object has been deleted" error.

Re: Hello Qt for Python

#128

Post by ffredrikk »

kbumsik wrote: post #89
stavros wrote: 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?

As you can see, Qt for Python is not yet stable release. So you will want to use PyQt5 first. I remcommand PyQt5 because there are more resouces available on the internet now. PyQt5 and Qt for Python is a 1-to-1 binding to the original Qt and their APIs are almost identical, so you should be able to switch to Qt for Python quite easily when it is stable. By the way, Qt for Python is re-branded from PySide2. They are…

PySide2 (Qt for Python) has been in production where I work (and in the visual effects industry) since 2016.

Since then, bugs have been smashed, modules have been added and improvements have been made. I would recommend almost anyone to start developing with this right away and, like always, report bugs [0] and contribute improvements back to the project [1] (not on github).

[0]: https://bugreports.qt.io/projects/PYSIDE/issues

[1]: http://code.qt.io/cgit/pyside/pyside-setup.git/

Re: Hello Qt for Python

#129

Post by mherrmann »

fernly wrote: post #115
mherrmann wrote: post #27

Earlier quoted context omitted.

Sorry to be spamming here but check out my https://github.com/mherrmann/fbs . It is literally the solution to your pain point.

No, interesting and useful. But a few questions. So basically you have automated the job of calling PyInstaller to make a standalone app, plus the step of wrapping the app in an installer. Yes? In order to use this, if I read the tutorial[1] code correctly, I must modify my app to wrap everything -- or at any rate, all PyQt-related things? -- inside an AppContext, and modify the outermost level to create this. If so,…

It's more than just automating the calling of PyInstaller. It also fixes some edge cases with PyInstaller-built apps that lead to crashes on some users' systems and took me months to figure out. Further, it integrates the solutions nicely. You don't have to learn how PyInstaller works, fbs does it for you with very reasonable default settings. You don't have to figure out how you are going to ship resource files and access them from within your app, etc.

Yes you should use the AppContext. You don't have to convert your entire app to it. Only enough to "start" your app. (I highly recommend the app context approach where possible however, it's just so clear.)

Re: Hello Qt for Python

#130

Post by xioxox »

lbeltrame wrote: post #100

I skimmed through the posts in the thread but no one seemed to mention the major pet peeve that (IMO) PyQt has, which is not the licensing, but the development model: 1. SIP files are generated and dropped into the tarball: no way to do that yourself (the tool is available, but completely undocumented). This is problematic when a new major Qt version is out, but PyQt hasn't updated yet (I had problems like this recen…

This isn't PyQt, but an update of PySide. However I find the PyQt developer very responsive to bug reports. It's a much better service vthan the usual post to a bug tracker and no response you get with many other projects.
Post reply on HN