I think I'm missing something here. What is the operation that this tool is meant to simplify?
This takes five minutes because you're copy-pasting a 250-line file. Which otherwise builds the layout manually. Doing that from scratch would easily take, what, an hour? even for an experienced Qt developer.
During that hour you can definitely read an introductory tutorial (from Qt's excellent documentation). Assembling that UI with the GUI builder then takes all of five minutes, maybe ten if you've never used it before. And you don't need Docker and a VM for that (!?).
Is this meant to showcase how easy it is to package the application? If so, that's definitely cool, but I'm not sure how it relates to the article, which starts with "This article shows how to program a Linux GUI. In five minutes from now, you will have created an app and a downloadable installer. We'll build the following GUI, but you can also create any other" -- and then goes on to show you neither how to program a Linux GUI, nor how to build that application (unless you count copy-pasting code as either of them?)
Edit: it's worth pointing out that cross-platform packaging Qt applications, especially written and Python definitely isn't too easy. If this is the point, then this program doesn't look bad at all!
> cross-platform packaging Qt applications, especially written and Python definitely isn't too easy. If this is the point, then this program doesn't look bad at all!
That's what it is about, yes, sorry. I should have written the article shows how to create a Linux GUI. I let myself be distracted by SEO considerations ("Linux GUI programming").
Well, it's not like you're showing anyone how to create a Linux GUI, either (unless, you know, you count the copy-paste part :-) ).
If SEO is the goal, perhaps it's worth looking into keywords along some other directions? A lot of folks who get past the "getting started with Qt" part is going to be interested in the problem of packaging Qt applications (especially where Python is involved, which comes with its own set of difficulties).
If these are the people such an article is relevant for, I doubt "Linux GUI programming" is the kind of stuff they're googling for. After all, they already know a little about that, the problem is how to let their friends use what they wrote already. Meanwhile, people who are googling things like "how to write gui program Linux" probably need help figuring out things like signals and slots, not how to package an application that they can't even write yet.
I do feel like I am showing people how to create a Linux GUI. After all, they do end up with a GUI.
I already have a few other articles targeting other key words, and I feel the unique contribution of this one (and the latest version of fbs, which this one aims to spread the word about) is a much better solution for ... Linux GUI programming. But I'll keep in mind what you said. I'm still pretty new to SEO.
SEO or not, the disappointment comes from expecting one thing, and then getting another.
When I clicked on the title, I expected to learn about how to create a Linux GUI. This article did not, in any way, shape or form, teach me anything about how to create a Linux GUI.
It introduces a tool which solves a problem I'm not sure I'm having, related to packaging (why would I care, it's the distributor's job anyway, no one using Linux should ever have to download an installer manually, ever)
SEO is not about promisig something, making them click, and then giving people something completely different. It's about targeting the needs of a group that has a particular pain, and addressing them well.
A better title might have been "package a standalone PyQT GUI application in minutes".
I like that the project supports AppImage. I don't suppose fman supports displaying AppImage icons? I've been keeping my eye out for any filemanager that does.
I guess it's better, but I'm with AnIdiotOnTheNet on this one :-). Packaging is definitely something important, and definitely not something that we ought to be looking down upon. Why avoid calling it by its name?
Ok, so others have pointed out that there isn't any GUI creation really going on here, so I'm not going to harp on that.
However, since we're on the topic of GUI creation, why isn't there a way for users to compose simple GUIs to meet their workflow needs? Something like HyperCard was?
Part of the reason a lot of people love the command line so much is how it allows you to compose solutions to unique problems in a simple way. Why doesn't that exist in the GUI? Where is the UNIX philosophy applied to the GUI?
Ok, so there's SmallTalk environments, but they're strange and require you to learn a whole new language and paradigm just to get started. Where's UNIX's answer?
Simple cross-platform GUIs are pretty easy in Racket, and there’s even a wealth of beginner-focussed teaching materials / documentation for Racket.
Less tutorial material for GUI apps specifically, which should probably be remedied. Still, Racket has a pretty good native GUI and packaging story, and the docs are very consistent.
Not quite what I'm talking about. For one, it is much closer to VB than HyperCard, and while HyperCard was great in the 90s it could be significantly improved upon today.
Also, no UNIX philosophy, that is the composability of small tools, to be seen.
For devs, Lua bindings with GTK+ (like JavaScript with QT/QML) would be a good solution: easy binding with C libs, and minimal runtime and easy distribution. It needs a VB6 GUI builder with code editor.
For users, a "parts" library built with the above and a layout/flow chart for building workflows.
As many else have been I have been click-baited here thinking you are going to teach us how to do PyQt5 GUI development faster and better. Now as I'm developing a PyQt5 GUI app I can say it involves a serious amount of of non-intuitive hand-coding and feels annoyingly hard and slow as compared to WinForms and WPF. It is most probably going to get easier and faster with experience, nevertheless I believe some real articles (going beyond hello-worldish stuff and addressing more complicated issues from a real-life experience perspective) on PyQt5 programming can probably help a lot (unfortunately there are hardly any published to the date).
> I can say it involves a serious amount of of non-intuitive hand-coding and feels annoyingly hard and slow as compared to WinForms and WPF. It is most probably going to get easier and faster with experience
No, it won't get easier, because the technology is flawed. If you want easy you use HTML. There is a reason all new complex applications are written in Electron.
The reason isn't a flaw in technology, because many alternatives to electron do in fact offer markup language like GUI creation and css/html like styling including Qt with its QML offshoot, or JavafX.
Not to mention that I don't see any obvious reason why HTML would be easier to use than the WPF / Swing / Glade Gui-builder paradigm. As a not web-developer, I certainly have less issues building a Gui the good old fashioned way than having to learn HTML.
It honestly baffles me that anyone would consider HTML to be a good fit for a complex desktop application. I am actually very glad that I can drag buttons on a canvas and click on elements to understand their apis and adjust settings visually. I am not excited about building complex gui's by interacting with plain text that was designed to put text on webpages.
The reason why Electron has dominated has a much more trivial reason. There are a lot of web developers, and the javascript ecosystem is so large that it allows the quick reuse of a lot of code, saving those developers a lot of time.
> many alternatives to electron do in fact offer markup language like GUI creation and css/html like styling including Qt with its QML offshoot, or JavafX.
> Not to mention that I don't see any obvious reason why HTML would be easier to use than the WPF
Can I use Vue.js or React over QML? That's a point many people miss. You think of HTML/JavaScript as the thing from 10 years ago that maybe you played with in school.
Vue.js/React is to HTML/CSS what WPF is to raw Win32 GUI programming.
> Can I use Vue.js or React over QML? That's a point many people miss. You think of HTML/JavaScript as the thing from 10 years ago that maybe you played with in school.
I'm not the author of the commend above but I actually do.
> Vue.js/React is to HTML/CSS what WPF is to raw Win32 GUI programming
Good explanation if it's true, thanks.
> Can I use Vue.js or React over QML? That's a point many people miss.
Does modern QML really lack facilities that solve the same problems with comparable ease?
I'm scared away from HTML/Electron as it seems (perhaps I'm wrong) that means I am going to have to also use Photoshop (which I'm particularly bad at) and design literally every bit of the UI from scratch while what I want is a set of classic widgets to layout on a form quickly (the way I do in VisualStudio and Qt Designer). I have experience of using HTML, CSS and vanilla JS to make classic web pages and I can't even imagine how to html/css-code something that is going to look and work like a reasonably complex desktop application. Also as @mherrmann has once mentioned "Do you know how JavaScript sorts numbers? Alphabetically. ’nuff said.". At least but not at last Electron apps are so slow to start and so hardware-hungry I actually doubt it is going to become a truly mainstream platform for desktop applications.
BTW the technology doesn't look flawed any more (arguably it is less flawed) than WinForms is. If only Trolltech would consider developing a WinForms-style (or call it Delphi-style) RAD studio (that would provide click-to-code experience, a visual BackgroundWorker component etc and let you customize everything visually instead of only doing the actual form design job like Qt Designer) a worthy investment PyQt5 apps development could be made a breeze.
> means I am going to have to also use Photoshop (which I'm particularly bad at) and design literally every bit of the UI from scratch while what I want is a set of classic widgets to layout on a form quickly
Exactly. What is the react/vue/html/css alternative for this? Because when I look around, I find ways of doing it but people generally do not seem to use them so they end up being abandoned. There is no reason why it cannot be simularly easy, but, as far as I see, people using these technologies like to keep things complex for the design-challenged among us.
> At least but not at last Electron apps are so slow to start and so hardware-hungry I actually doubt it is going to become a truly mainstream platform for desktop applications
Nobody is going to write a Photoshop or a music production software in Electron. You need C++ for that kind of stuff. Neither PyQt or WinForms cuts it. Apps like that use custom GUIs built directly over OpenGL/Direct3D.
But I have a feeling your app is no Photoshop either.
Well, this does require copying-and-pasting the entire GUI script, so I wouldn't exactly say this takes less than 5 minutes if you're writing that stuff from scratch
This strikes a nice balance between open source GPL and commercial licensing and services, and I like how this makes it easy to distribute your application. I keep reading comments here on HN about how nice QT is to work with, and this seems like a great way to jump in.
This is really cool as Qt just looks daunting to start with! Is there a way to make it use native widgets? I noticed the app in the screenshots doesn't look like native Ubuntu.
There is no such thing as "native Ubuntu" :-). The default widget style of a modern Ubuntu installation is just a GTK theme (which, I think, supports both GTK 3 and GTK 2 -- the two are incompatible, so themes need to implement support for both). You can configure Qt to use the GTK 2 rendering engine, but GTK 2 and GTK 3 look slightly different for reasons that I am entirely unable to convey without an inflammatory post, so Qt (and GTK 2) applications won't look exactly the same as GTK 3 applications.
I am not sure how this is going (this blog post is the only info I can find on it) but they have plans to make a new UI library for Qt that is backed by the platform's native widgets, like AppKit on macOS:
Writing doesn't count as "something you've made", because then every post would be a Show HN. We make exceptions for books because those are so much more work.
Am I missing something? It's obvious to me he's showcasing the "fman build system": https://github.com/mherrmann/fbs which is a wonderful project because the only reason I avoided Python + Qt in the past was because I wanted to make a very very simple cross-platform installer for my friends (mac and windows) and I didn't want to spend a lot of time researching how to bundle the python runtime in a cross-platform binary.
Personally, this is the most useful "Show HN" project I've seen in the past months.
Interesting, I didn't know about blog posts and Show HN. It is less of a blog post than an announcement of a new library though. Either way, I'm fine with the removal of the show prefix and will remember it for future posts. Thanks.
Although I understand value behind this approach, what I specifically dislike about fman is the fact its own instances of CPython, Qt and other libraries get installed together with it although I already have up-to-date versions of all the dependencies properly installed in my system.
Yes, absolutely. You can follow the exact same steps as in the article; Just use Python 3.5 or 3.6 and omit the `buildvm` and `runvm` steps. The only limitations on Windows are that the app is not yet code signed and there are no automatic updates (yet).
Qt as an ecosystem is fairly complete for general application development. It includes, among other things, concurrency primitives (QtConcurrent) that are trivial to use*, sockets, database support, serial port drivers and charting (qwt for example). Plus lots of useful tidbits I keep finding like accessing standard system temp directories, making temporary files and adding registry keys (or equivalent).
I've never used GTK in anger, but presumably there's some feature overlap. At times I've used Qt without any GUI components because it's so convenient (nicer than Boost for sure).
It also leverages native GUI frameworks so most applications will blend in with the platform you're writing for (last time I tried GTK this wasn't the default). It's easy to style with CSS if you need it.
From the perspective of a Windows user, GTK+ 3 does a less-good job of fitting in than Qt Widgets 5. Even with the win32 theme (GTK seems to use the Adwaita theme by default) GTK is missing shadows and the icon gutter in menus, and animations on push buttons and scrollbars. Qt Widgets 5 (with the Windows style, not the Fusion style) gets those right, and as a result, Qt apps look much more like native apps.
GTK+3 fits well only into GNOME. If you want to make an app that works and behaves well under other DEs, Windows or macOS, then even GTK+2 would be a better choice. Basic stuff works, but as soon as you want to use something more platform specific, like notifications, event sounds, systray, platform native decorations etc. then GTK+3 is going to give you a hard time.
Another python GUI that’s not as fancy but easy to use is http://easygui.sourceforge.net
I used it to create a GUI for on of my programs at work took me 10 minutes to program.
Writing a PyQt5 app is still as much of a ballache as writing a GUI in anything is. Certainly takes a lot of "minutes". The article just downloads a preprepared application.
What TFA is really doing is selling (unless you're GPL) an application that packages this all up. All things you could do for yourself, but that take an amount of effort.
I didn't pick the current title - it was set by a mod. And yes, PyQt still takes time. And yes, you could do packaging & deployment yourself. But it will take weeks or months, depending on how many platforms you target. Why reinvent the wheel?
Definitely not portable (not that the author claimed to be).
When I’ve taken up building a Qt all idea, it’s usually because I want to build a program for a non-technical user. There really is no easy way to build easily portable or cross platform Qt apps. I had high hopes with Go but even that requires system packages (last time I checked).
You can use PySide2 instead of PyQt. And you don't need a Qt license when just using it from Python, because Qt is licensed under the LGPL and you are allowed to link to it dynamically.
So, if putting your project under the GPL is not an option for you, then the only commercial license you need is fbs.
This takes five minutes because you're copy-pasting a 250-line file. Which otherwise builds the layout manually. Doing that from scratch would easily take, what, an hour? even for an experienced Qt developer.
During that hour you can definitely read an introductory tutorial (from Qt's excellent documentation). Assembling that UI with the GUI builder then takes all of five minutes, maybe ten if you've never used it before. And you don't need Docker and a VM for that (!?).
Is this meant to showcase how easy it is to package the application? If so, that's definitely cool, but I'm not sure how it relates to the article, which starts with "This article shows how to program a Linux GUI. In five minutes from now, you will have created an app and a downloadable installer. We'll build the following GUI, but you can also create any other" -- and then goes on to show you neither how to program a Linux GUI, nor how to build that application (unless you count copy-pasting code as either of them?)
Edit: it's worth pointing out that cross-platform packaging Qt applications, especially written and Python definitely isn't too easy. If this is the point, then this program doesn't look bad at all!
That's what it is about, yes, sorry. I should have written the article shows how to create a Linux GUI. I let myself be distracted by SEO considerations ("Linux GUI programming").
If SEO is the goal, perhaps it's worth looking into keywords along some other directions? A lot of folks who get past the "getting started with Qt" part is going to be interested in the problem of packaging Qt applications (especially where Python is involved, which comes with its own set of difficulties).
If these are the people such an article is relevant for, I doubt "Linux GUI programming" is the kind of stuff they're googling for. After all, they already know a little about that, the problem is how to let their friends use what they wrote already. Meanwhile, people who are googling things like "how to write gui program Linux" probably need help figuring out things like signals and slots, not how to package an application that they can't even write yet.
I already have a few other articles targeting other key words, and I feel the unique contribution of this one (and the latest version of fbs, which this one aims to spread the word about) is a much better solution for ... Linux GUI programming. But I'll keep in mind what you said. I'm still pretty new to SEO.
When I clicked on the title, I expected to learn about how to create a Linux GUI. This article did not, in any way, shape or form, teach me anything about how to create a Linux GUI. It introduces a tool which solves a problem I'm not sure I'm having, related to packaging (why would I care, it's the distributor's job anyway, no one using Linux should ever have to download an installer manually, ever)
SEO is not about promisig something, making them click, and then giving people something completely different. It's about targeting the needs of a group that has a particular pain, and addressing them well.
I like that the project supports AppImage. I don't suppose fman supports displaying AppImage icons? I've been keeping my eye out for any filemanager that does.
However, since we're on the topic of GUI creation, why isn't there a way for users to compose simple GUIs to meet their workflow needs? Something like HyperCard was?
Part of the reason a lot of people love the command line so much is how it allows you to compose solutions to unique problems in a simple way. Why doesn't that exist in the GUI? Where is the UNIX philosophy applied to the GUI?
Ok, so there's SmallTalk environments, but they're strange and require you to learn a whole new language and paradigm just to get started. Where's UNIX's answer?
Less tutorial material for GUI apps specifically, which should probably be remedied. Still, Racket has a pretty good native GUI and packaging story, and the docs are very consistent.
Also, no UNIX philosophy, that is the composability of small tools, to be seen.
For users, a "parts" library built with the above and a layout/flow chart for building workflows.
No, it won't get easier, because the technology is flawed. If you want easy you use HTML. There is a reason all new complex applications are written in Electron.
Not to mention that I don't see any obvious reason why HTML would be easier to use than the WPF / Swing / Glade Gui-builder paradigm. As a not web-developer, I certainly have less issues building a Gui the good old fashioned way than having to learn HTML.
It honestly baffles me that anyone would consider HTML to be a good fit for a complex desktop application. I am actually very glad that I can drag buttons on a canvas and click on elements to understand their apis and adjust settings visually. I am not excited about building complex gui's by interacting with plain text that was designed to put text on webpages.
The reason why Electron has dominated has a much more trivial reason. There are a lot of web developers, and the javascript ecosystem is so large that it allows the quick reuse of a lot of code, saving those developers a lot of time.
> Not to mention that I don't see any obvious reason why HTML would be easier to use than the WPF
Can I use Vue.js or React over QML? That's a point many people miss. You think of HTML/JavaScript as the thing from 10 years ago that maybe you played with in school.
Vue.js/React is to HTML/CSS what WPF is to raw Win32 GUI programming.
UI systems like Qt and Swing have had the concept of a component tree with independently replaceable and renderable subtrees for 20 years or more.
I'm not the author of the commend above but I actually do.
> Vue.js/React is to HTML/CSS what WPF is to raw Win32 GUI programming
Good explanation if it's true, thanks.
> Can I use Vue.js or React over QML? That's a point many people miss.
Does modern QML really lack facilities that solve the same problems with comparable ease?
BTW the technology doesn't look flawed any more (arguably it is less flawed) than WinForms is. If only Trolltech would consider developing a WinForms-style (or call it Delphi-style) RAD studio (that would provide click-to-code experience, a visual BackgroundWorker component etc and let you customize everything visually instead of only doing the actual form design job like Qt Designer) a worthy investment PyQt5 apps development could be made a breeze.
Exactly. What is the react/vue/html/css alternative for this? Because when I look around, I find ways of doing it but people generally do not seem to use them so they end up being abandoned. There is no reason why it cannot be simularly easy, but, as far as I see, people using these technologies like to keep things complex for the design-challenged among us.
Nobody is going to write a Photoshop or a music production software in Electron. You need C++ for that kind of stuff. Neither PyQt or WinForms cuts it. Apps like that use custom GUIs built directly over OpenGL/Direct3D.
But I have a feeling your app is no Photoshop either.
See https://news.ycombinator.com/item?id=18397380
One ends up re-parenting and moving things around so much that it's easier to be agile in a GUI than it is with code.
http://blog.qt.io/blog/2017/02/06/native-look-feel/
Writing doesn't count as "something you've made", because then every post would be a Show HN. We make exceptions for books because those are so much more work.
Personally, this is the most useful "Show HN" project I've seen in the past months.
I've never used GTK in anger, but presumably there's some feature overlap. At times I've used Qt without any GUI components because it's so convenient (nicer than Boost for sure).
It also leverages native GUI frameworks so most applications will blend in with the platform you're writing for (last time I tried GTK this wasn't the default). It's easy to style with CSS if you need it.
I would assume that the same is also the case on macOS.
THat's just an emotional "feeling". For hard facts, just compare the file picker dialogs.
Writing a PyQt5 app is still as much of a ballache as writing a GUI in anything is. Certainly takes a lot of "minutes". The article just downloads a preprepared application.
What TFA is really doing is selling (unless you're GPL) an application that packages this all up. All things you could do for yourself, but that take an amount of effort.
Definitely not portable (not that the author claimed to be).
When I’ve taken up building a Qt all idea, it’s usually because I want to build a program for a non-technical user. There really is no easy way to build easily portable or cross platform Qt apps. I had high hopes with Go but even that requires system packages (last time I checked).
So, if putting your project under the GPL is not an option for you, then the only commercial license you need is fbs.
(Caveat: IANAL)