I like the tutorial, but I don't know why you would use PyQt these days. Tkinter is more permissive and has wrappers like appJar which make it disgustingly easy to put together a quick, ugly GUI. If you're building a desktop app that needs to really look good and be fast, why are you using Python?
In my research [1] [2] [3], Tkinter was said to be better for basic applications, PyQt better for more advanced projects. 1: https://stackoverflow.com/a/1094530/1839209 2: https://www.reddit.com/r/learnpython/comments/108zfq/tk_or_q... 3: https://www.quora.com/Should-I-use-PyQt-GTK3-or-tkinter-for-...
PyQt5 Tutorial: Create a Python GUI in 2018
141–150 of 211 posts
Re: PyQt5 Tutorial: Create a Python GUI in 2018
#142Still using tkinter here which is python's default GUI, what's the license for PyQt5? For me learning Qt in general is another big investment of limited time, so far I have been using tkinter with python and it works well.
Pyside/"Qt for Python" is LGPL.
You then need a license for QT, which is LGPL or commercial. You can use the LGPL version of Qt with commercial PyQt, but I never understood the hoops you might have to jump through in order to comply with the LGPL. Packaging python apps is painful enough without having to worry about that, might as well spend a little to avoid the aggravation. LGPL Qt also lacks a few advanced packages.
Re: PyQt5 Tutorial: Create a Python GUI in 2018
#143Earlier quoted context omitted.
The "threading" functionality in Python is a significant downside to the language. I don't know why they went with the idea that people don't need real threads like they can get in C/C++, Java, C#.
Python threads are real (operating system) threads. Note that the "threading" and "_threading" modules wrap thread creation and otherwise just use interpreter C APIs. Their design flaw is that they assume that they are the only ones using the interpreter API.
Re: PyQt5 Tutorial: Create a Python GUI in 2018
#144Re: PyQt5 Tutorial: Create a Python GUI in 2018
#145Earlier quoted context omitted.
Python threads are real (operating system) threads. Note that the "threading" and "_threading" modules wrap thread creation and otherwise just use interpreter C APIs. Their design flaw is that they assume that they are the only ones using the interpreter API.
I assume parent is referring to the GIL, which limits the performance benefits you get from threads.
Re: PyQt5 Tutorial: Create a Python GUI in 2018
#146Earlier quoted context omitted.
The API still looks messy and unpythonic though, sadly. Look at the basic hello world example. Why do I need to pass QApplication an empty array? Why am I calling a method ending with _ to launch the program? And the fact the label magically attaches to the app through some side effect is also confusing. Does anyone know if there's any good shim/wrapper around PyQt that has a better API?
The now-official bindings (Qt for Python as mentioned in the article) has a waaay more Pythonic API. I actually liked it. The advantage of PyQt5 is that you can look up the Qt documentation.
Re: PyQt5 Tutorial: Create a Python GUI in 2018
#147Earlier quoted context omitted.
Looking at a tutorial, it looks like all it does is layout the form for you. That's a shame. Things closer to what the original VB was are sorely missed in modern computing.
It gives you ui for connecting signals and slots and configuring stuff as well, but few people use it. And qt singals and slots model is far superior to VB/Delphi style callbacks or c# delegates, but you have to program for a while to get why. Also - layouts in VB/Delphi weren't responsive, layouts made in QtDesigner are.
I try hard to do that (it saves on boilerplate), but the challenge is always in finding signals and slots with the same precise amount of parameters. Say I trigger a signal with no parameters and I want to connect it to a slot that takes a boolean always with the same value (e.g. a pressed() connected to a setEnabled(bool), where bool should always be True), I can't do that in Designer, it has to be in actual code - a trivial one-liner, sure, but still one more line of technical debt.
(INB4 "ur doing it wrong": yes, I know about clicked(bool), toggled(bool) etc, it was just an example to explain the concept.)
Re: PyQt5 Tutorial: Create a Python GUI in 2018
#148Earlier quoted context omitted.
The now-official bindings (Qt for Python as mentioned in the article) has a waaay more Pythonic API. I actually liked it. The advantage of PyQt5 is that you can look up the Qt documentation.
Qt for Python and PyQt5 have almost exactly the same API, to the point where it took me 30 min to migrate my 15kLoC project [1] from the latter to the former, mostly by changing a few imports. Maybe you meant something else? 1: https://fman.io
Re: PyQt5 Tutorial: Create a Python GUI in 2018
#149Earlier quoted context omitted.
that's an interesting definition of "non-ugly". I would hesitate a lot before making an app that looks like this screenshot public.
well it's a bit old school but it certainly looks functional. If the program under it is good, it's a very superficial comment. If only you'd see my emacs screen, it's unbelievably ugly and somehow, I work with it every day !
* https://assets.guitar-pro.com/1.3/images/www/guitar-pro-7/ca...
* https://www.awn.com/sites/default/files/styles/original/publ...
* http://www.comptoir-hardware.com/images/stories/_software/am...
it's not what I use myself, being more of an i3/terminal guy, but it's absolutely what the clients want