Fbs: Create Linux GUIs with Qt in minutes
build-system.fman.io
build-system.fman.io
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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)