Live data from Hacker News

Show HN: Cross-platform desktop applications with PyQT

github.com

191–200 of 293 posts

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

#191
post #156

Earlier quoted context omitted.

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.

Sure, but if you don't have events of your own to process, either you're constantly calling processEvents() and spinning the CPU, or you're in a loop that does so every second, which is both high-latency and inefficient (and bad for battery life). You generally want to process an event when it suits the event, not when it suits you :-)

It looks like this is done by subclassing QAbstractEventDispatcher and filling out virtual functions registerSocketNotifier(), registerTimer(), etc. I suppose you could do this for asyncio/Twisted, but I'd prefer to import something where someone has done this for me and is accepting bug reports from the community, because this is the sort of thing that's made of edge cases that are hard to notice in testing.

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

#192

Earlier quoted context omitted.

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 co…

I've used QML before, but I appreciate you linking a sample for anyone who's curious.

Re: the matter at hand, it's cool if you don't consider that bloated. If I was using a C++ Qt codebase as the comparison point, I might think that too. However, if we're comparing it to a typical web codebase, that's an order of magnitude more dense. This also just doesn't matter in 2018, because QML could have the best documentation in the world and you'll still have trouble figuring out any issues as it doesn't have anywhere near the level of literature and/or (discoverable, not buried in some dead Linux project) open source code that the web platform does. Qt has a sexy problem, and every time it's brought up people try to claim it doesn't matter, but it does.

(There's also a slew of apps (e.g, I could go pick a cryptocurrency wallet app at random...) that have been built long after 2012 and still have issues with rendering.)

I'm not interested in debating KDE, since... that project stopped being relevant to me around KDE4. Nothing but wasted potential.

Re: respecting a Desktop theme... I used to love ricing out my desktop too. ;P

The thing is that it's an archaic viewpoint - one that you're welcome to have, but it'll increasingly be pushed down. Product design is always going to trump desktop UI customization capabilities, because one of those has money behind it and the other doesn't.

I also don't know anybody who customizes their desktop chrome anymore because (in addition to companies like Apple making it next to impossible) most people use their machines through a web browser at this point.

Also, let me be clear: I would love for native UI frameworks to be better. I don't particularly enjoy digging around in web codebases, but pretending that anything is else is as close to approachable as them makes it very difficult for any native UI toolkit to improve. People seem to think it's on the Web to catch up to the performance of native, but it's really the reverse - native needs to play the game how the web does or it's going to go extinct.

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

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

As it happens QT does support rich text inside labels. Basically it can interpret a subset of HTML markup to render complex labels. See [1]

[1] http://doc.qt.io/archives/qt-4.8/richtext-html-subset.html

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

#194
post #191

Earlier quoted context omitted.

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

Sure, but if you don't have events of your own to process, either you're constantly calling processEvents() and spinning the CPU, or you're in a loop that does so every second, which is both high-latency and inefficient (and bad for battery life). You generally want to process an event when it suits the event , not when it suits you :-) It looks like this is done by subclassing QAbstractEventDispatcher and filling ou…

I've used variations of qt4reactor (https://pypi.python.org/pypi/qt4reactor/1.6) to integrate Twisted with PyQt apps. It usually works pretty well for desktop apps (I used it to create an ssh tunnel using twisted conch for a desktop database visualization too).

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

#195

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…

For an internal GUI application, Java/Swing is actually a mature solution. With Groovy and Swingbuilder, writing a swing GUI is quite easy.

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

#196

Earlier quoted context omitted.

> Except this sucks if, you know, you want to make some money on your app... Why is that a problem? You get a commercial license for PyQt and are good to go(?) > I love Python, but it has stagnated hard in the last few years. The 2 to 3 transition really hurt the Python ecosystem [...] I disagree. I think the ecosystem is more vibrant than ever. > Furthermore, packaging for different platforms is still a problem in 2…

$500 dollars... is "not expensive"? Beside the ML/AI sub-community, I am having a hard time finding GUI innovation in the Python ecosystem. Perhaps, you could show me an option that doesn't suck? I've tried Kivy, PyQt, PySide, Eel, gooey, etc... I am not a JS dev and had an electron/react app up and running that I easily ported to my Android phone in under an hour.

https://github.com/billsix/pyNuklear

  if nuklear.button_label(title="Button"):
         print("Button pressed!")

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

#198

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…

People like you hate the idea of using JavaScript to write desktop apps because you feel like the end result is too slow and inefficient. Web developers hate the idea of using C++ to write desktop apps because the language is brittle, outdated, and overly complex. We need a middle ground: a language with the syntax of a scripting language, like Python or JavaScript, that compiles down to native code, like C++ or Rust…

Nim[0]? Ante[1]? Perhaps even D, although that's pushing it.

0: https://nim-lang.org/

1: https://github.com/jfecher/ante

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

#199
post #156

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…

> If someone has a high-quality way to use asyncio or Twisted with the Qt event loop, I'd probably bump Python a bit higher

I've experimented around with Quamash[1] a bit with Asyncio and it seems to work nicely! Looking at CI it seems to have some rough edges (at least on Windows) though.

https://github.com/harvimt/quamash

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

#200
post #173
post #41

I have been developing in HTML/Python for a while now. This works wonderfully. You just need to put all your business logic in Python, use PyQt to run all the platform specific code like file dialogs, printing, etc. but keep the main interface with React. You do that by having a webview with a service object being the bridge between Python and the JS view[0]. If you are a bit careful with the amount of information go…

I'm assuming this is a desktop app, not running off a server. How do you get round the problem of distributing Python with every install? Or do you just accept it? I love Qt in C++ because most of the time the code just recompiles between Mac/Windows/Linux. I've shied away from writing GUIs in Python because deploying - to the point where a non-technical user can run the program - always ends up being hacky.

That is literally the point of the original post.
Post reply on HN