Live data from Hacker News

Show HN: Cross-platform desktop applications with PyQT

github.com

221–230 of 293 posts

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

#221

Earlier quoted context omitted.

Rust might eventually get to that point, and C++ itself with QT is relatively easy if you stick to the basics. But in a way, anything trying to please both higher level and lower level developers is going to have to settle for some kind of middle ground. The best situation I can think right now, and the one I would adopt myself, is indeed PyQt. Mostly because Python makes it easy to drop the compute-heavy application…

Rust has been harder for me to pickup than C++. I want to like it. The problem is that the one character symbolic syntax notation remain nonsensical and seem arbitrary to me.

You should probably try D then. It's easy to pick up and very powerful once you learn most of the language features.

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

#222

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…

Well, we have Vala. It compiles to C just like Nim and it's used for GUIs, although it's Gtk specific and some would argue it's not a programing language:

https://blogs.gnome.org/despinosa/2017/02/14/vala-is-not-a-p...

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

#223

I'm really curious why anyone would want to do this. You'll almost surely arrive at something equally slow and awkward as Electron, but without the cutting edge interpreter, accessibility, or text support... Chromes rendering engine is objectively better than Qt's for an awful lot of things. What you may win back is a gig of ram that wasn't really being used anyways...

In my case, it was Electron's startup performance that made me go for PyQt [1]. [1]: https://fman.io/blog/picking-technologies-for-a-desktop-app-...

I am happy you found something that worked for you. But to me, I'm just very frustrated. People consistently suggest Qt is a net good because Electron uses more RAM and just totally abandon accessibility. The proliferation of Electron is one of the single most progressive things to happen on the front of general desktop application accessibility for folks with special visual or motor control needs since OS's started addressing these needs directly

Let's just contrast and compare: The ENTIRE story for Qt accessibility is tree navigation, with trust that readers exist: http://doc.qt.io/qt-5/accessible-qwidget.html

Meanwhile Electron has an auditing tool for a wide range of accessibility requirements which also explains how you can fix the problems: https://github.com/electron/spectron#accessibility-testing

But congrats now we can run 2 tabbed text editor instances at once. Because for some crazy reason we're going to pretend Electron apps aren't competitive on $30 computers but IntelliJ is immune to criticism.

On a more emotional and personal level, in my entire time using linux since 1995, I've never once used a Qt app I liked. I wrote them professionally, and I hated each one and felt ashamed of the outputs.

To me, to then layer Python on top is like taking stale bread and slathering on that curiously pale, overly sweet peanut butter that they use on airlines. It's quite possibly the most Nope thing you could say other than, "Oh and also we embedded an APL interpreter and you'll need to write C++ circa 1995 for memory management."

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

#224

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. 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 documentatio…

> However, if we're comparing it to a typical web codebase, that's an order of magnitude more dense

Well, I disagree. All the examples I could find, for instance in Vue.js, React, etc... had quite a bit more LOC necessary to achieve the same behaviour, when counting JS + CSS + HTML. Even with lambdas, associating a behaviour to an object is still not as nice as just doing `height: width/2` and knowning that the constraint will keep being enforced.

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

These certainly were troubled times, but KDE5 is honestly really nice. See the latest release https://www.kde.org/announcements/plasma-5.12.0.php

> The thing is that it's an archaic viewpoint - one that you're welcome to have, but it'll increasingly be pushed down.

Will it ? in the contrary I find that the ricing community is more active than ever :p Ricing was a thing with e16 and blackbox when there were less than 100k linux users two decades ago. Now there are more than a hundred million... it's not going to disappear. Besides, it's sometimes a necessity. Think for instance of all the vision-problem-related enhancements that a coherent desktop theme can provide.

> I also don't know anybody who customizes their desktop chrome anymore

www.reddit.com/r/unixporn

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

#225
post #3

Not directly related to the initiative itself, but comparing and contrasting the Electron website vs. PyQT is striking: https://riverbankcomputing.com/software/pyqt/intro https://electronjs.org/ I've been a (proud) Pythonist for years now, and I've always been a bit chagrined by the quality of the "marketing" of Python projects. It doesn't at all reflect the quality of the community and the projects.

Its 15 years older.

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

#226

Earlier quoted context omitted.

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.

Neither are as good as 99% of the tools available for development with HTML/CSS. [...] 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.

I have a feeling that you do not have any actual experience with Qt Designer or RAD tools? Designing a user interface quickly is many times easier in Qt, Delphi, etc. than in HTML/CSS. It start with the basic fact that Qt has many useful widgets that are not available in plain HTML, nor many CSS/Javascript frameworks. From there it is just drag and drop, adding a few spacers here and there and you are done.

Plus, with HTML/CSS, you can work manually on your project, without any special tool besides your browser,

Why would I develop in such an arcane manner if I already have great development tools for more than two decades?

Again, I recommend anyone who only has HTML/CSS experience to look beyond their bubble. We had RAD tools with Delphi 1.0 in 1995, where you could build a user interface using drag and drop and associate code with event by simply double clicking a widget in the interface builder. I built GUI applications in Delphi as a 13-year old because it was trivial, even without an internet connection, StackOverflow, etc.

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

#227

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

That is correct, the Windows binary is an online installer. The reason for this is that fman uses Google Omaha for its auto-update mechanism [1].

The Arch package is smaller because it declares PyQt as a dependency, rather than shipping it itself. The reason for this is that it was difficult otherwise to make the shipped version of PyQt libraries and dependencies compatible with the ones already on the system.

[1]: https://fman.io/blog/google-omaha-tutorial/

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

#228
post #3

Not directly related to the initiative itself, but comparing and contrasting the Electron website vs. PyQT is striking: https://riverbankcomputing.com/software/pyqt/intro https://electronjs.org/ I've been a (proud) Pythonist for years now, and I've always been a bit chagrined by the quality of the "marketing" of Python projects. It doesn't at all reflect the quality of the community and the projects.

If I was picking one based on their website, I'd no doubt go for PyQT. "Marketing" is just a eulogy for lying I think. And it further annoys me when FOSS projects imitate IT companies and try to do marketing.

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

#229

I write desktop apps using PyQt and build an installer with pynsist. This is cross-platform, but I only need Windows support. Other than that, is this project just a simplified way to build desktop applications, or would it produce something fundamentally different from what I'm building now?

It would build something similar but encapsulate knowledge gained from distributing to many thousands of machines. For instance, about .dlls that are available 99% of the time but sometimes missing on some users' machines [1].

[1]: https://github.com/mherrmann/fbs/blob/cb0d57e59c9fecf24fb281...

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

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

That would be Visual Basic, Delphi, Smalltalk, Hypercard.
Post reply on HN