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

161–170 of 293 posts

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

#161

Post by mattgreenrocks »

loftyal wrote: post #153
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…

Could you give me some examples of "Computer Science has had "had tools for the right jobs"". Thanks

SQL comes to mind here.

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

#162

Post by dijit »

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…

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 amount more than you write code.

Priority #4: Writing. A software should spend the least amount of time on a CPU being written.

I'm not saying that you should only focus on making fast/slick runtimes that are easily debuggable above literally everything else; but you should absolutely have slanted priorities towards this goal.

And in that respect, why wouldn't you learn the right tool for the job?

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

#163

Post by pritambaral »

ihnorton wrote: post #131

I am curious about final package size on various platforms when using this project. The download bundles for the related "fman" project vary considerably -- Win: 1MB; macOS: 23MB; Ubuntu: 39MB. The last number matches my experience with scripted Qt applications, at which point the size is comparable to a typical ~50-70 MB Electron app, at least for compressed downloads. Visual Studio Code is 44 MB on Windows and 65MB…

I'd wager the Windows download is not the full app, rather just an installer. There's no way Qt and PyQt would fit in just 1MB on an OS that doesn't include those as shared libraries.

As a side note: I see the Arch Linux package is 16M, unlike Ubuntu's 39M. Perhaps the app needs a relatively recent Qt or PyQt release that is available from Arch's repos but not on the oldest supported Ubuntu and thus needs to be shipped.

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

#164

Post by JoeAltmaier »

dijit wrote: post #162
geofft wrote: 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…

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

So, for most coding most of the time on most projects, write dead-obvious code using normal design patterns and simplest abstractions. Because time is money, and your wetware time is millions of times more expensive than cpu time.

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

#165

Post by geofft »

dijit wrote: post #162
geofft wrote: 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…

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…

> The point is that we unnecessarily focus on developer comfort in writing software, but software needs to be optimised first and foremost for runtime.

My argument is about runtime, not about developer comfort - if you have race conditions between threads, or deadlocks, or blocking I/O on the UI thread, that's a runtime problem, not a developer comfort problem.

(I do also disagree with your priorities, in part because if you get #4 right you avoid a lot of #2, but I wanted to be clear about what my argument is.)

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

#166

Post by [deleted] »

camgunz wrote: post #152
throwawayfinal wrote: post #105

Earlier quoted context omitted.

When the "good Desktop development framework" is primarily in javascript, it's a good signal.

There are a lot of counter-examples: - apache - lighttpd - v8 - PostgreSQL - Linux - Go - ZeroMQ - any imaging library (libpng, libjpeg) - any compression library (zlib, xz, bzip2) - urxvt - vim - emacs - tmux Basically none of these have good websites. When I'm looking for a CSS framework or like, UI tricks like scriptaculous then I think it's a good signal, but past that I really think there's no link here. Really…

[deleted]

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

#167

Post by cheez »

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…

Why are JavaScript programmers even relevant? Do they, as a group, have some desirable skill other than "will code for food"? At least successful C++ programmers HAVE to be decent-ish. The language is unforgiving.

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

#168

Post by Mononokay »

microtonal wrote: post #106
addicted wrote: post #56

Earlier quoted context omitted.

Linux and Mac weren’t as popular OSes either. And frankly, Windows apps didn’t need to look decent because people on the Windows/Linux side of the world were ok with really bad looking apps. Now that Desktop apps compete with web apps those toolkit’s are falling short. They are falling short in ease of development, cross compatibility, lack of trained developers (relative to web), and lack of good looking UIs and UI…

Have you ever designed an application with Qt Designer or Delphi for that matter? Both are literally drag and drop. You can make a first mock-up of a application in a few minutes. I have developed some larger Qt applications and in each case there are at most a couple dozen of lines with platform-specific code. Qt abstracts away most of the platform differences. For me ‘good looking UIs and UI patterns’ means: well i…

Neither are as good as 99% of the tools available for development with HTML/CSS. Plus, with HTML/CSS, you can work manually on your project, without any special tool besides your browser, and see the effects you have on the layout in real time.

Delphi/Qt Designer look way worse than any HTML/CSS/JS GUI builder, too - along with having interfaces equivalent to what GIMP's is to Photoshop.

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

#169

Post by chocolatebunny »

kelnos wrote: post #114
horsawlarway wrote: post #42

Earlier quoted context omitted.

Wow. You realize they share most of the same code, and are essentially feature identical? Seriously, open the desktop app, then open the web app. They're identical. Precisely because they chose to use a toolkit that let them easily handle cross platform issues with UI in a sane and repeatable manner.

> You realize they share most of the same code, and are essentially feature identical? Yes. So why would I run essentially a second web browser instance to run the same code in a different place? Beyond that, I had with weird screen refresh issues with the desktop app, where scrolling or even just typing in the text box would cause parts of the main HTML view to just disappear to the point where it'd be unusable. Oft…

I wish Chrome apps for the desktop were more popular. Use the browser you're using anyways but on a thing that sort of acts like an application.

I installed the Netflix chrome app on my Windows PC. It's basically the Netflix webpage on a separate application window that doesn't have tabs or a search bar.

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

#170

Post by z3t4 »

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…

finally someone who understands JS while most other devs trying JS dont know events, have a hard time understanding async and complain about lack of threads - in JS you can spawn worker process's but that wont help if you dont understand events/async. everything in JS is event based eg button.onclick and while it might feel old you can never abstract that away as the cpu uses interups that is basically events. that is how computers and the real word works. for example if a coworker comes into your office thats an interupt. you have a routine/function for it and tells him to fuck off. but at the same time your manager comes in. that is the nature of async. and you might have an edge case you did not think about.
Post reply on HN