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

Show HN: Cross-platform desktop applications with PyQT

github.com

Post reply on HN
Print view View original

181–190 of 293 posts

Re: Show HN: Cross-platform desktop applications with PyQT

#181

Post by pfranz »

jimnotgym wrote: post #174

Coding is only a part of my job. I am currently building an application for our warehouse, connecting our ERP to some external services. Lots of moving parts across several machines. In the middle is a tiny GUI, which has been more trouble than the rest put together. I used Tkinter to minimise dependencies. I am staggered by how much code it takes to get a GUI working (compared to the rest of the project), and this i…

How would javascript reduce the code necessary for a gui or help you cross platform? UIs are very different between phone / desktop so even if you stayed with javascript you'd be learning different libraries or rewriting everything to conform to the other platform.

Personally, I tend to use QtDesigner to layout apps and Qt for implementation (this applies for PyQt/PySide or C++). It tends to reduce the code necessary to get something up and going and helps keep things more MVC.

Tkinter is the standard UI library for Python, but I haven't used Tk in close to 15 years. Tk worked well enough for smaller Perl or Tcl apps, but when I first moved to Python professionally (around 2005) I bounced between WxWidgets, PyGTK, and PyQt. Qt was always ahead of the rest, but had licensing concerns at the time. I feel like there's a bit of roughness conceptually between Qt and Python that are just fundamental, but I think that's more on Python and asynchronous needs of UIs.

I was trying to figure out when this decision was made. I see references of tkinter dating back to 1999 (tk is from 1991), but it looks like it was officially included along with Python starting in 2008. If true, I would think it would be obvious it wouldn't be the best general choice going forward by that time. But I can see the reasoning behind choosing it due to licensing, size, volatility of api.

Re: Show HN: Cross-platform desktop applications with PyQT

#182

Post by jcelerier »

_em6m wrote: post #4

The main problem with "other toolkits" vs Electron apps is that they are not as simple to use in order to create a very good looking UIs. Compare how easy it is to use HTML and CSS in order to create a very complex UIs with all sort of effects vs how utterly complicated is to override, let's say, Qt's ::paint() method in order to achieve rich text inside a label. Let me repeat it. Rich text inside a label. Such a sim…

Here's how to do a TodoMVC with Qt. It takes less than 150 CLOC tops. No need to override whatever paint method anywhere. https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qm...

Re: Show HN: Cross-platform desktop applications with PyQT

#183

Post by marmaduke »

geofft wrote: post #156
guhcampos wrote: post #144

Unfortunatelly PyQt does not solve the problem of Javascript engineers who are not willing to learn a new programming language. That's the whole reason for the whole Javascript fadigue. Computer Science has had "had tools for the right jobs" for years, but now we have a large developer base that only knows Javascript and think it's some kind of holy grail of computing. Happened before with Java. Happened before with…

Speaking as a developer who primarily writes Python and secondarily C, Rust, C++, bash, and others as necessary, who has in fact worked on a large-scale C++ UI project in Qt on the Linux desktop running alongside PyGTK UIs, and who doesn't actively write JavaScript, I have to say that JavaScript is a really good choice of language, especially for UI, because it has a strong bias towards event-based programming and ca…

You don’t have to use Qt’s event loop: you can just call app.processEvents() when it suits you.

Re: Show HN: Cross-platform desktop applications with PyQT

#184

Post by jcelerier »

carlos22 wrote: post #37
_em6m wrote: post #4

The main problem with "other toolkits" vs Electron apps is that they are not as simple to use in order to create a very good looking UIs. Compare how easy it is to use HTML and CSS in order to create a very complex UIs with all sort of effects vs how utterly complicated is to override, let's say, Qt's ::paint() method in order to achieve rich text inside a label. Let me repeat it. Rich text inside a label. Such a sim…

QLabels support a subset of html and are styleable with simple css rules. But yes no animations or stuff like that.

There's plenty of stuff for fluid animations in Qt : https://qmlbook.github.io/ch05/index.html

Re: Show HN: Cross-platform desktop applications with PyQT

#185

Post by flukus »

JoeAltmaier wrote: post #164
dijit wrote: post #162

Earlier quoted context omitted.

The point is that we unnecessarily focus on developer comfort in writing software, but software needs to be optimised first and foremost for runtime. In fact I'd put the priority as such: Priority #1: Runtime, your code will (hopefully) be run a lot more than it does anything else. Priority #2: Debug, your code will be debugged more than it is read Priority #3: Reading, you will probably read your code a significant…

Most code, #1 is irrelevant. Most code isn't in the inner loop of performance-limiting execution. Given that, what makes sense to optimize for? The slowest, most error-prone processor in the mix is, the wetware in your head. So, almost all of the time, put #1 at the bottom of the list. Put #3 next, because once it works, the slowest process is relearning why it works, necessary to debug or extend it. #2 and #4 are si…

> Most code, #1 is irrelevant. Most code isn't in the inner loop of performance-limiting execution.

Just because your code isn't in a tight loop doesn't mean you shouldn't think about performance. If you waste CPU resources then the rest of the system that is in a tight loop will have more switches to do. If you waste memory then the code in the tight loop will have memory evicted from it's precious memory cache. Just because your process is not CPU bound does not mean you aren't having an impact on overall system performance.

If you're running your own servers do whatever you want, but if you're making consumer software then don't pretend you're software is the only thing running.

Re: Show HN: Cross-platform desktop applications with PyQT

#186

Post by jcelerier »

Klonoar wrote: post #145
nabla9 wrote: post #128

Earlier quoted context omitted.

Here is an example of modern UI build with Qt: https://www.youtube.com/watch?v=f7en65HkjeQ&t=39

That's a killer UI, and I'm happy to admit it's incredibly good for what I've seen/used of Qt apps over the years... but it's not the norm. I would honestly pay money to see how much effort it took to get it to this. There's also the point I forgot to mention in my original post, which is that... if your entire app starts as a webapp, there's no sense in maintaining an entire separate Qt codebase when you could just…

> That's a killer UI, and I'm happy to admit it's incredibly good for what I've seen/used of Qt apps over the years... but it's not the norm.

It's the norm for Qt apps since 2011 - 2012 when qml was introduced (of course, older apps use the older tech - and honestly, sometimes it makes more sense : at least all the colors, fonts, etc... will respect your desktop theme unlike "modern" toolkits). Here's how some QML code looks: https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qm... ; as you can see, it's far from bloated (mostly due to the language being based on reactive semantics).

For instance a consequent part of KDE has been rewritten in QML and more is underway with Kirigami : https://dot.kde.org/2017/01/12/kde-releases-kirigami-ui-20

Re: Show HN: Cross-platform desktop applications with PyQT

#187

Post by electricslpnsld »

_em6m wrote: post #4

The main problem with "other toolkits" vs Electron apps is that they are not as simple to use in order to create a very good looking UIs. Compare how easy it is to use HTML and CSS in order to create a very complex UIs with all sort of effects vs how utterly complicated is to override, let's say, Qt's ::paint() method in order to achieve rich text inside a label. Let me repeat it. Rich text inside a label. Such a sim…

> The main problem with "other toolkits" vs Electron apps is that they are not as simple to use in order to create a very good looking UIs.

What Electron apps are good examples of ones that look very good? Slack and VS Code both look fairly bland, and Spotify is a bit of an over-energetic mess, at the moment.

Re: Show HN: Cross-platform desktop applications with PyQT

#189

Post by flukus »

snerbles wrote: post #178
djsumdog wrote: post #141

Earlier quoted context omitted.

I prefer the pyqt website. No stupid animations. No bullshit. Just clear links to all the information you need, easily available docs, etc. I mean, it's kind a real reflection of the two frameworks. Do you want a framework that requires a 90MB payload with it that's a resource hog and a web browser or do you want something small, light and works?

We want that, but we are the minority. I do agree that PyQt has a respectable documentation page. It is, however, a terrible page for attracting new developers and selling decision makers on the idea of using it.

> It is, however, a terrible page for attracting new developers and selling decision makers on the idea of using it.

Would that be attracting people that are worth attracting though? Just like in business, not all customers are worth having.

Re: Show HN: Cross-platform desktop applications with PyQT

#190

Post by wiremine »

snerbles wrote: post #178
djsumdog wrote: post #141

Earlier quoted context omitted.

I prefer the pyqt website. No stupid animations. No bullshit. Just clear links to all the information you need, easily available docs, etc. I mean, it's kind a real reflection of the two frameworks. Do you want a framework that requires a 90MB payload with it that's a resource hog and a web browser or do you want something small, light and works?

We want that, but we are the minority. I do agree that PyQt has a respectable documentation page. It is, however, a terrible page for attracting new developers and selling decision makers on the idea of using it.

> a terrible page for attracting new developers

This is a better way of identifying my frustration: open source projects don't just need good docs, they need to attract and inspire... especially visual frameworks like a GUI.

Post reply on HN