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

PyQt5 Tutorial: Create a Python GUI in 2018

build-system.fman.io

Post reply on HN
Print view View original

201–210 of 211 posts

Re: PyQt5 Tutorial: Create a Python GUI in 2018

#201

Post by tlamponi »

sytelus wrote: post #197

How is the experience of other folks here? I have found QT as true nightmare. The UX created with QT just doesn’t scale with 4K displays and framework is just pain to maintain on OS like Windows. I rather prefer UX frameworks that uses web technologies any day.

I run Linux without desktop environment on a 4K screen, so I ran into this stuff on all GUI kits. I set the respective scale detection/factor variable in my environment and be done, e.g., for QT5 it'd be:

export QT_AUTO_SCREEN_SCALE_FACTOR=1

for auto scaling. See: https://blog.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-... and https://wiki.archlinux.org/index.php/HiDPI#Qt_5 for more options and other UI kits.

Normally, the desktop environment should do this for you, though. But yeah, this was quite horrible for me for a long time and only got better recently (~ 1 to 2 years), with an wider adoption of high DPI screens, I'd guess.

Re: PyQt5 Tutorial: Create a Python GUI in 2018

#202

Post by meredydd »

pjmlp wrote: post #194
rkeene2 wrote: post #101

Earlier quoted context omitted.

Here you go: vTcl -- just like Visual Basic 3.0. Also, you get to use Tcl instead of Visual Basic, so even better ! http://vtcl.sourceforge.net/

Visual Basic 6 compiled to actual native code though, while TCL teached me to never use such languages beyond bare scripting tasks. Even Visual Basic 3's P-Code interpreter was faster than TCL string based one.

What was the last version of TCL you used? These days they have an extremely cunning system involving multiple representations: Being TCL, every value is of course canonically a string, but if you do (eg) integer operations the result will be stored only as an integer until its needed as anything else. And the body of a 'proc' will be compiled to bytecode on first use, so subsequent calls will go much faster. One could even add a specialising JIT to this if you wanted to.

Re: PyQt5 Tutorial: Create a Python GUI in 2018

#203

Post by pjmlp »

meredydd wrote: post #202
pjmlp wrote: post #194

Earlier quoted context omitted.

Visual Basic 6 compiled to actual native code though, while TCL teached me to never use such languages beyond bare scripting tasks. Even Visual Basic 3's P-Code interpreter was faster than TCL string based one.

What was the last version of TCL you used? These days they have an extremely cunning system involving multiple representations: Being TCL, every value is of course canonically a string, but if you do (eg) integer operations the result will be stored only as an integer until its needed as anything else. And the body of a 'proc' will be compiled to bytecode on first use, so subsequent calls will go much faster. One cou…

Version 8.x, the ones where bytecodes where introduced (1999 - 2003).

Thing is, if you want to speak about modern TCL implementations, then the comparison needs to be against VB.NET, with its 64 bit SIMD aware JIT/AOT compilers.

Re: PyQt5 Tutorial: Create a Python GUI in 2018

#204

Post by anentropic »

dagw wrote: post #193
Upper_0nion wrote: post #175

Too bad it's only for Python3 and installing both 2 and 3 is complicated. Would be a good program if it supported python2.

There are several tools that make having both python 2 and 3 running trivial. Pipenv and conda are probably the two better ones. On the whole you should probably using one of them even if all your development is done with the same python version

pyenv

pipenv is dependency management on top of that

Re: PyQt5 Tutorial: Create a Python GUI in 2018

#206

Post by megous »

TheAceOfHearts wrote: post #120
megous wrote: post #113

Earlier quoted context omitted.

I see a simple electron app using 140MB total. Measured by running 'free -m' before and after starting the app and waiting a while for a gc to run. Measuring memory use is difficult.

FYI, you can open dev tools in electron and manually trigger GC [0]. [0] https://i.imgur.com/JbWArmR.png

I'm sure opending dev tools will increase memory use significantly though. So it's a bit self-defeating. :)

Perhaps there's some API to call instead.

Re: PyQt5 Tutorial: Create a Python GUI in 2018

#207

Post by kbutler »

krferriter wrote: post #128
blattimwind wrote: post #116

Earlier quoted context omitted.

> (but I wouldn't cross the streams with python threads) You can't. Also keep in mind that Python's thread-local storage only works with the threading module threads, not Python threads created elsewhere (e.g. by the "outer" C++ application itself or by a QThread wrapper). It's really quite poorly implemented there IMHO.

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#.

> 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#

Well, for one reason, the choice for Python (or the implementation we now call CPython) was made when you couldn't get what you think of as "real threads" in C/C++, and Java and C# did not yet exist.

Like many engineering choices, there are tradeoffs. The choice to implement Python memory management with reference counting and thus a global interpreter lock was made in an era when garbage collection was much less advanced, when most C libraries were not thread safe, and multi-core CPUs were mainly large computer installations.

As the stack overflow post https://softwareengineering.stackexchange.com/questions/1868... describes, there are advantages to an interpreter lock.

Now you know why.

But the world has changed in ways that make the disadvantages much more prominent. Unfortunately, efforts to remove it have failed because they slow down single-thread performance (which remains quite important) or break backward compatibility, etc.

Re: PyQt5 Tutorial: Create a Python GUI in 2018

#208

Post by rkeene2 »

pjmlp wrote: post #203
meredydd wrote: post #202

Earlier quoted context omitted.

What was the last version of TCL you used? These days they have an extremely cunning system involving multiple representations: Being TCL, every value is of course canonically a string, but if you do (eg) integer operations the result will be stored only as an integer until its needed as anything else. And the body of a 'proc' will be compiled to bytecode on first use, so subsequent calls will go much faster. One cou…

Version 8.x, the ones where bytecodes where introduced (1999 - 2003). Thing is, if you want to speak about modern TCL implementations, then the comparison needs to be against VB.NET, with its 64 bit SIMD aware JIT/AOT compilers.

Also, modern Tcl can be compiled to machine code to a large degree thanks to TclQuadCode and LLVM.

Re: PyQt5 Tutorial: Create a Python GUI in 2018

#209

Post by pjmlp »

rkeene2 wrote: post #208
pjmlp wrote: post #203

Earlier quoted context omitted.

Version 8.x, the ones where bytecodes where introduced (1999 - 2003). Thing is, if you want to speak about modern TCL implementations, then the comparison needs to be against VB.NET, with its 64 bit SIMD aware JIT/AOT compilers.

Also, modern Tcl can be compiled to machine code to a large degree thanks to TclQuadCode and LLVM.

Interesting I wasn't aware of it, how mature is it?

Re: PyQt5 Tutorial: Create a Python GUI in 2018

#210

Post by ehsankia »

blattimwind wrote: post #105
ehsankia wrote: post #96

Earlier 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?

Since Python 3 you can use exec() instead of exec_() (in Python 2 exec was a keyword). > And the fact the label magically attaches to the app through some side effect is also confusing. Are you referring to the first "label.show()" example? Typically that pattern is rare (~once per app for the main window). Regarding attachment to the app; QApplication is a process-wide singleton. All objects belong to the same app.

Thank you for the explanation, and the keyword issue makes sense.
Post reply on HN